WO2013102716A1 - Procede dynamique de determination d'une liste de services dans un reseau sip - Google Patents

Procede dynamique de determination d'une liste de services dans un reseau sip Download PDF

Info

Publication number
WO2013102716A1
WO2013102716A1 PCT/FR2012/052930 FR2012052930W WO2013102716A1 WO 2013102716 A1 WO2013102716 A1 WO 2013102716A1 FR 2012052930 W FR2012052930 W FR 2012052930W WO 2013102716 A1 WO2013102716 A1 WO 2013102716A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
services
list
operator
determining
Prior art date
Application number
PCT/FR2012/052930
Other languages
English (en)
Inventor
Thibaut Coadic
Olivier Cleuziou
Bruno Tossou
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
Priority to EP12815740.1A priority Critical patent/EP2801178B1/fr
Priority to US14/370,161 priority patent/US10608898B2/en
Publication of WO2013102716A1 publication Critical patent/WO2013102716A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H04L41/5012—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF] determining service availability, e.g. which services are available at a certain point in time
    • 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/1069—Session establishment or de-establishment
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
    • H04M2207/20—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place hybrid systems
    • H04M2207/203—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place hybrid systems composed of PSTN and data network, e.g. the Internet
    • 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/42136—Administration or customisation of services

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 enable a user of this network to discover dynamically, that is to say during the registration on the network or subsequently, the services to which he actually has access.
  • SIP session control protocol
  • a device-client "User Equipment” in English) "belongs" to the network of a given operator, hereinafter referred to as “network-operator", when the user of this client device has an account with of this operator, regardless of the access network used by the client device to connect to the network operator.
  • 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 NETF in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol. The SIP protocol was then extended by NETF into several other RFC documents, adding new features to the SIP protocol.
  • 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 is defined by the 3rd Generation Partnership Project (3GPP). It is a network architecture originally introduced for mobile networks and then extended to other accesses, including fixed access xDSL technology. 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 services such as telephony, videophone, Presence and Instant Messaging, which it also manages interaction.
  • the client device of the user must, with some exceptions (in the case of certain emergency calls), register on the network. When the network is unable to link this record to a previous record (for example due to a network failure, or following a client-device shutdown for a duration longer than a predetermined value), the record is considered being an initial recording. After an 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 words “Serving - Call Session Control Function” meaning “Session Call Control Function”). ), 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 Session Control Function” meaning “Interrogating Call Session Control Function”) - moreover often combined physically with the servers of type S-CSCF to constitute servers denoted “l / S-CSCF” - which, at the time of the registration of a device-client, interrogate a server called "HSS” (initials of the English words " Home Subscriber Service "means” Subscribing Subscriber Service ”) to select an S-CSCF server that has the characteristics that are mandatory (and, if applicable, optional) required to achieve the service level subscribed by the user.
  • HSS Home Subscriber Service
  • the HSS servers each contain a client database, and are thus the equivalent in the IMS 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.
  • IBCF server initials of the English words “Interconnection Border Controller Function” meaning “Control Function of Interconnection Border ”: These are SIP servers located at the edge of the IMS network and implementing the specific processing required, if necessary, to interconnect with another SIP network. This IBCF function is often performed by SBC-type equipment (initials of the words “Session Border Controller” meaning “Border Session Control”) or l-SBC.
  • this choice depends on the service offer to which the user has subscribed. It also depends on the client device used by the user and the technical characteristics of the latter: in fact, the client device can give the illusion that it can invoke services that the user does not actually have. right, or conversely do not allow the user to use certain services to which he has nevertheless duly subscribed.
  • the access connectivity may be provided by a first network, for example a local network in the country visited by the user.
  • this first network may not be directly connected to the network operator, so that the use of at least one additional transit network is necessary.
  • each of these networks may have their own technical characteristics, and these networks may not all have the means to provide the services that the user could access if he were directly connected to his network operator. Even if these networks would individually have such means, it is possible that the operators who manage them have not concluded the prior interconnection agreements necessary for the end-to-end implementation of certain technical characteristics required for the user to make full use of his service offer.
  • the aim is to avoid giving the user false information, in order to prevent the user from attempting to invoke services that can not be honored, which would cause the user to unnecessary traffic in the network and a risk of misunderstanding and dissatisfaction on the part of the user;
  • FIG. 1 This problem is illustrated in Figure 1.
  • a user (denoted “U” in the figure) has subscribed to services S1, S2, S3, S4 and S5 from his service operator.
  • the client device (denoted “T” in the figure) that it uses to connect to the network has the means to provide services S2, S3, S4, S5 and S6.
  • the user is traveling in a foreign country, and he uses the network of a local operator in the country he visits (network noted “RM” in the figure) as an intermediate network to connect to the network operator (noted “ RO "in the figure).
  • RM has the means to provide services S1, S3, S4, S5 and S6.
  • RM has no direct connection with the RO operator network, and uses a transit network (denoted "RI2" in the figure) to join the RO operator network.
  • This intermediate network RI2 has the means to provide all the services S1, S2, S3, S4, S5 and S6, but the interconnection agreement between the intermediate RI2 and the operator network RO does not provide compatibility with the service S3. .
  • S4 and S5 are accessible to the user U, but the latter will think, on the basis of the compatibility indications provided by T, that the services S2, S3, S4, S5 and S6 are accessible to him, and may attempt unsuccessfully the use of services S2, S3 and S6.
  • the operator network RO will think that services S2, S3, S4 and S5 are accessible, while the transmission to T of requests relating to services S2 and S3 will lead to a failure.
  • a user registered with an IMS network may submit from this network a service package and broadcast services related to the reception of television channels via the Internet (IPTV); the network allows the required services to the extent that they are compatible with the subscription of the user to the network operator, and the user is informed of what the network has authorized.
  • ETSI European Telecommunications Standards Institute
  • the visited network ie ie the network used at a given time by the client-device to ensure its connectivity
  • IMS voice over PS parameter sessions
  • SIP / IMS emergency services Emergency Service Support
  • the operator of the user can also, according to the standard 3GPP TS 24.167, configure the services it offers and / or authorizes in the client device. But this is by definition a static provision: an update of this recording session information per recording session would be exceedingly cumbersome to implement; moreover, it assumes the deployment of a configuration infrastructure, which is not guaranteed. Above all, this list of services does not take into account the possible limitations that the existence of intermediate networks could bring.
  • the present invention therefore relates to a method for determining a list of services for the user of a client device belonging to a network operator, said network operator implementing the SIP session control protocol.
  • the method is remarkable in that it comprises the following steps: said client device inserts into a registration request to the network operator a list of services that it has the technical means to provide,
  • each intermediate network used to connect the client device with the operator network transmits said registration request to said operator network after having deleted or marked in said list of services all the services that said intermediate network does not have the technical means to provide and / or for which the intermediate network does not have a usage agreement with the operator of the upstream and / or downstream network to which it is connected, and
  • the network operator obtains a list, called the definitive list, by extracting from the list of services contained in the registration request received those of them to which the user of the client device is entitled, taking into account his subscription to network operator, among the services that the network operator has the technical means to provide.
  • the present invention proposes the transmission, during a registration request, of the list of available services between a client device and its operator network, and the modification of this list, if necessary, by the different networks. SIP crossed. The network operator can thus become acquainted with all the services that are actually available and authorized end-to-end.
  • said method then comprises the following steps:
  • said network operator inserts said definitive list in a response to said registration request
  • said response is transmitted without modification of the final list to said client device via, if necessary, said intermediate networks.
  • the user of the client device and, where appropriate, the intermediate networks can also see the list of services that this user can actually access.
  • a subsequent service request for example a request of the SIP INVITE or SIP SUBSCRIBE type
  • the user of the client device will advantageously limit himself to requesting the provision of services chosen from those to which he can actually access.
  • the invention relates to a device for determining a list of services in a SIP network, said first network, characterized in that it has means for:
  • said device further has means for transmitting to a SIP network, said third network, to which said first network is connected, said registration request after having deleted or marked in said modified list, if any, all services for which the operators of the first network and the third network have not established a mutual usage agreement.
  • the invention in another aspect, relates to a session control server comprising a device as briefly described above. According to the same aspect, the invention relates to a interconnection server comprising a device as briefly outlined 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 method of determining a list of services succinctly set forth above, when executed on a computer.
  • FIG. 1 already described, represents the services accessible, according to the state of the art, to a user connected to his network operator via two intermediate networks,
  • FIG. 2 schematically represents the structure of a network
  • FIG. 3 represents, according to an embodiment of the invention, a method of determining the services actually accessible to a user connected to his operator network via two intermediate networks.
  • SIP networks in general, an exemplary embodiment will now be considered an IMS network architecture as briefly described above. This architecture is illustrated in Figure 2.
  • the multimedia services offered by this IMS RO network may for example include telephony services, video telephony, content-sharing ("content-sharing" in English), presence, instant messaging, or television. These services are available to the user of an UE 10 client device, which can exchange SIP-compliant multimedia streams and session control signals over this RO network, in particular with another UE client device. 1 1, the client devices 10 and 1 1 having previously registered with the network RO.
  • the client device 10, 1 1 can be a fixed or mobile terminal, or a home or enterprise gateway, or a software on a PC or on a smartphone, having SIP signaling means and which can include means of restitution. audiovisual content.
  • this multimedia service delivery system relies on a RO network according to the IMS architecture defined in 3GPP, and which comprises:
  • an L / S-CSCF call server 22 in particular manages the procedure for registering the devices connected to the network RO; in fact, for such a device to benefit from the services provided by this network, this device must, with some exceptions (in the case of certain emergency calls) register with the server l / S-CSCF 22; the l / S-CSCF server 22 also manages the routing of the signaling between the client device 10 and the VM 25 voicemail servers, PS 26 presence and TAS 27 telephony servers, as well as the routing towards other terminals managed by the same IMS network (as for example the client device 1 1) and the routing of the signaling between this IMS network RO and other networks (not shown);
  • the P-CSCF server 28 is the SIP contact point of the client device 1 1 in the IMS network RO; thus, all the SIP signaling exchanged between the client device 1 1 and the l / S-CSCF call server 22 passes through this server P-CSCF 28;
  • an HSS server 24 contains the profile of the user of the client device 10 in terms of authentication data, location and subscribed services;
  • the IBCF server 33 is located at the edge of the IMS network, and implements the specific processing necessary, if necessary, to perform an interconnection (not shown) with another SIP network;
  • the VM server 25 allows the filing of a voice message by a caller such as the client device 1 1, when the called client device 10 can not take the call;
  • PS presence server s
  • the server PS 28 manages the subscription of the client device 10 to the presence events that the user of this terminal wishes to monitor, and notifies the terminal at the occurrence of these events; and • one (or more) TAS 27 telephony server (s); a TAS server manages the telephone services to which the user of the client device 10 has subscribed with his operator, such as the presentation of the number or call forwarding.
  • the VM 25 voicemail servers, the PS presence servers 26 and the TAS telephony servers 27 are examples of so-called “application servers” (AS).
  • AS application servers
  • the present invention relates to a SIP operator network RO and, where appropriate, to the intermediate network (s) SIP (RI 1, RI2, and so on) traversed by a registration request issued. by a client device 10 to the RO operator network to which this client device 10 belongs. At least one of these networks may advantageously be an IMS type network.
  • a client device T 10 initiates a registration procedure with its operator network RO. To do this, it issues a registration request SIP REGISTER, and it inserts a list of services that it has the means to provide (and that the user U of the client device T, 10 wishes to use as long as it will remain saved).
  • this registration request is received in an intermediate network RI 1 by a P-CSCF 29, which deletes in said list the services that the network RI 1 does not have the technical means to provide (the list of services that the network 1 has the means to provide that can for example be statically configured in all the P-CSCF servers of the network 1); alternatively, the intermediate network RI 1 can preserve the received list, but add an indication including its network identifier and those services with which it is not compatible; this second variant (assuming that it is applied by all the intermediate networks) enables the operator network RO to be aware of the initial list requested by the client device and to determine which particular intermediate network is at the origin of a particular restriction.
  • the P-CSCF server 29 transmits the request to an IBCF 31 network RI 1 interconnecting with an intermediate network RI 2 to join the network operator RO.
  • This IBCF 31 can in turn modify the list according to the services negotiated with RI 2, for example by referring to a table giving, for each interconnected network, the list of authorized services.
  • an IBCF server 32 (or several IBCF servers) of the network RI 2 repeats these operations according to the services that the network RI 2 has the means to provide, services negotiated with the network RI 1 and services negotiated with RO, before transmitting the request to an IBCF server 33 of the network RO.
  • This IBCF server 33 can in turn modify the list received according to the interconnection agreements between RO and RI 2, before transmitting the request to a server I-CSCF RO.
  • this l-CSCF server by means of the interrogation of the HSS 24, selects the S-CSCF which will manage the recording of the client device T.
  • This S-CSCF modifies the list in turn. according to the services that the network-operator RO has the technical means to provide.
  • the operator network RO obtains a list, called the definitive list, by extracting from the list of services thus obtained those of whom the user U of the client device T 10 is entitled, taking into account his subscription to the service provider. network operator RO.
  • step E5 the operator network RO inserts this final list in a response 200 OK to the request REGISTER.
  • this answer 200 OK is transmitted, without modification of the final list, to the client device T, 10 via the intermediate networks RI2, then RM.
  • steps E1 to E4 allow the operator network RO to acquire, within the list of services that the client device T, has the technical means to provide, those which are moreover compatible with intermediate networks.
  • the set of steps E5 to E7 enables the client device T, 10, and possibly the intermediate networks, to also discover the list of services actually accessible to this user U as long as it remains registered.
  • IMS Communication Service Identifiers IMS Communication Service Identifiers
  • ICSI IMS Communication Service Identifiers
  • the extension according to the present invention is to allow the intervention of the intermediate networks on this list of service identifiers, and to provide that the operator network RO refers to the client device T, the list of services to which the latter can actually access.
  • new SIP headers are defined for determining a list of services according to the invention (this list may, in particular, take the form of a list of ICSI identifiers); these new SIP headers will be referred to as "P-Requested-Services" and "P-Supported-Services".
  • the client-device T, 10 inserts a P-Requested-Services header in the SIP REGISTER request with the list of services that it has the technical means to provide;
  • each intermediate network RM, RI 2 relays this header by deleting or marking the identifiers of non-compatible services (due to a technical inability or lack of ad hoc agreements);
  • the operator network RO compares the list received with the list of services to which the client device T 10 is entitled among the services that the operator network RO has the means to provide, and returns the common subset by means of the P-Supported-Services header of the 200 OK REGISTER;
  • the intermediate networks RM, RI 2 relay this header without modifying it.
  • the invention can be implemented within the nodes, for example session control servers or interconnection servers, SIP networks, by means of software and / or hardware components.
  • the software components can be integrated into a typical network node management computer program. Therefore, as indicated above, 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 can be used to execute a computer program including instructions for implementing any of the methods of determining a service list according to the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for performing the steps of a method of determining a list of services according to the invention, when executed on a computer.
  • 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 a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means such as a hard disk, or a USB key ("USB flash drive" in English).
  • 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 methods of determining a service list according to the invention.

Landscapes

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

Abstract

Procédé dynamique de détermination d'une liste de services dans un réseau SIP La présente invention concerne un procédé de détermination d'une liste de services pour l'utilisateur (U) d'un dispositif-client (T, 10) appartenant à un réseau-opérateur (RO), ledit réseau-opérateur (RO) mettant en œuvre le protocole de contrôle de session SIP. Ce procédé comprend les étapes suivantes : ledit dispositif-client (T, 10) insère (E1) dans une requête d'enregistrement auprès du réseau-opérateur (RO)une liste de services qu'il a les moyens techniques de fournir; le cas échéant, chaque réseau intermédiaire (RI1, RI2) utilisé pour mettre en relation le dispositif client (T, 10) avec le réseau-opérateur (RO) transmet (E2, E3) ladite requête d'enregistrement vers ledit réseau-opérateur (RO) après y avoir supprimé ou marqué, dans ladite liste de services, tous les services que ledit réseau intermédiaire (RI1, RI2) n'a pas les moyens techniques de fournir et/ou pour lesquels le réseau intermédiaire (RI1, RI2) ne possède pas d'accord d'usage avec l'opérateur du réseau amont et/ou aval auquel il est connecté; et le réseau-opérateur (RO) obtient une liste, dite liste définitive, en extrayant (E4) de la liste de services contenue dans la requête d'enregistrement reçue ceux d'entre eux auxquels l'utilisateur (U) du dispositif-client (T, 10) a droit, compte tenu de sa souscription auprès du réseau-opérateur (RO), parmi les services que le réseau- opérateur (RO) a les moyens techniques de fournir. Application aux réseaux IMS. Figure pour l'abrégé : Fig. 3

Description

PROCEDE DYNAMIQUE DE DETERMINATION
D'UNE LISTE DE SERVICES 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 permettre à un utilisateur de ce réseau de découvrir de façon dynamique, c'est-à-dire lors de l'enregistrement sur le réseau ou subséquemment, les services auxquels il a effectivement accès.
On dira qu'un dispositif-client (« User Equipment » en anglais) « appartient » au réseau d'un opérateur donné, appelé ci-dessous « réseau-opérateur », 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-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 NETF 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 par NETF dans plusieurs autres documents RFC, ajoutant de nouvelles fonctionnalités au protocole SIP.
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 est défini par l'organisme de normalisation 3GPP (« 3rd Génération Partnership Project »). C'est une architecture de réseau introduite initialement pour les réseaux mobiles, puis étendue à d'autres accès, dont les accès fixes à technologie xDSL. 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 il 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 dispositif-client 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 Session Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), 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 Session Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») - 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 Service » signifiant « Service d'Abonné de Rattachement »), 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 IMS 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.
Enfin, en périphérie du réseau IMS peuvent se trouver un ou plusieurs serveur(s) IBCF (initiales des mots anglais « Interconnection Border Controller Function » signifiant « Fonction de Commande de Frontière d'Interconnexion ») : il s'agit de serveurs SIP situés à la bordure du réseau IMS et mettant en œuvre les traitements spécifiques nécessaires, le cas échéant, pour réaliser une interconnexion avec un autre réseau SIP. Cette fonction IBCF est souvent réalisée par un équipement de type SBC (initiales des mots anglais « Session Border Controller » signifiant « Commande de Session en Bordure ») ou l-SBC.
Dans le cadre d'un réseau et de services utilisant le protocole de contrôle de session SIP, le choix de services auxquels peut avoir accès un utilisateur à un instant donné dépend de différents facteurs.
Ainsi, ce choix dépend de l'offre de services à laquelle l'utilisateur a souscrit. Il dépend aussi du dispositif-client utilisé par l'utilisateur et des caractéristiques techniques de celui-ci : en effet, le dispositif-client peut donner l'illusion qu'il peut invoquer des services auxquels l'utilisateur n'a en fait pas droit, ou inversement ne pas permettre à l'utilisateur d'utiliser certains services auxquels il a pourtant dûment souscrit.
Ce choix dépend également des différents réseaux intermédiaires utilisés pour mettre en relation le dispositif-client et le réseau-opérateur. Par exemple, en situation de mobilité, la connectivité d'accès peut être assurée par un premier réseau, par exemple un réseau local au pays visité par l'utilisateur. De même, ce premier réseau peut ne pas être directement connecté au réseau-opérateur, de sorte que l'utilisation d'au moins un réseau de transit supplémentaire est nécessaire. Or chacun de ces réseaux peut avoir des caractéristiques techniques propres, et ces réseaux peuvent ne pas tous posséder les moyens pour fournir les services auxquels pourrait avoir accès l'utilisateur s'il était directement connecté à son réseau-opérateur. Quand bien même ces réseaux posséderaient individuellement de tels moyens, il se peut que les opérateurs qui les gèrent n'aient pas conclu les accords d'interconnexion préalables nécessaires à la mise en œuvre de bout en bout de certaines des caractéristiques techniques requises pour que l'utilisateur puisse faire plein usage de son offre de services.
Il y a un double enjeu à ce que le dispositif-client de l'utilisateur et le réseau-opérateur puissent déterminer quels sont les services effectivement accessibles à l'utilisateur :
• pour le dispositif-client, il s'agit d'éviter de restituer à l'utilisateur une information erronée, afin d'éviter que celui-ci ne tente d'invoquer des services qui ne pourront être honorés, ce qui causerait à la fois du trafic inutile dans le réseau et un risque d'incompréhension et de mécontentement chez l'utilisateur ;
• pour le réseau-opérateur, il s'agit d'éviter d'adresser au dispositif- client des requêtes vouées à l'échec, ce qui causerait une consommation inutile de ressources.
Ce problème est illustré sur la figure 1 . Sur cette figure, un utilisateur (noté « U » sur la figure) a souscrit aux services S1 , S2, S3, S4 et S5 auprès de son opérateur de service. Le dispositif-client (noté « T » sur la figure) qu'il utilise pour se connecter au réseau possède les moyens pour fournir les services S2, S3, S4, S5 et S6. L'utilisateur est en déplacement dans un pays étranger, et il utilise le réseau d'un opérateur local au pays qu'il visite (réseau noté « RM » sur la figure) comme réseau intermédiaire pour se connecter au réseau-opérateur (noté « RO » sur la figure). RM possède les moyens pour fournir les services S1 , S3, S4, S5 et S6. Or RM ne dispose d'aucune connexion directe avec le réseau- opérateur RO, et utilise un réseau de transit (noté « RI2 » sur la figure) pour joindre le réseau-opérateur RO. Ce réseau intermédiaire RI2 possède les moyens pour fournir tous les services S1 , S2, S3, S4, S5 et S6, mais l'accord d'interconnexion entre le intermédiaire RI2 et le réseau- opérateur RO ne prévoit pas la compatibilité avec le service S3. Au final, seuls S4 et S5 sont accessibles à l'utilisateur U, mais ce dernier pensera, sur la base des indications de compatibilité fournies par T, que les services S2, S3, S4, S5 et S6 lui sont accessibles, et risque de tenter en vain l'utilisation des services S2, S3 et S6. De même, le réseau-opérateur RO pensera que les services S2, S3, S4 et S5 sont accessibles, alors que l'émission vers T de requêtes relatives aux services S2 et S3 conduira à un échec.
Il existe dans l'état de l'art différents procédés permettant à un dispositif-client d'acquérir des informations sur les services qui lui sont accessibles.
Ainsi, selon la norme TS 183 063 de l'ETSI (European Télécommunications Standards Institute) (cf. notamment la Section 5.3.1 .1 et l'Annexe A.4.1 ), un utilisateur enregistré auprès d'un réseau IMS peut présenter auprès de ce réseau une requête de fourniture de services (« service packages and broadcast services ») liés à la réception de chaînes de télévision via Internet (IPTV) ; le réseau autorise les services requis dans la mesure où ils sont compatibles avec la souscription de l'utilisateur auprès de l'opérateur du réseau, et l'utilisateur est informé de ce que le réseau a autorisé.
Cependant, lorsqu'un réseau-opérateur accepte de fournir un tel service, il ne tient pas compte d'éventuelles limitations techniques que pourraient apporter ce réseau-opérateur lui-même, ou, le cas échéant, des réseaux intermédiaires entre lui et le dispositif-client de l'utilisateur, de sorte que, dans des cas de figure défavorables, le service ne sera finalement pas fourni à l'utilisateur malgré l'autorisation donnée par le réseau-opérateur.
Inversement, dans le cas spécifique des accès mobiles normalisés par le 3GPP (« 3rd Génération Partnership Project »), il est prévu (selon la norme 3GPP TS 23.401 ) que, lors de l'attachement radio, le réseau visité (c'est-à-dire le réseau utilisé à un instant donné par le dispositif-client pour assurer sa connectivité) indique spontanément au dispositif-client s'il est apte à fournir le service voix SIP/IMS (paramètre « IMS voice over PS sessions ») et les services d'urgence SIP/IMS (paramètre « Emergency Service Support »). Mais ces dispositions sont limitées aux services que l'on vient de mentionner, alors que l'utilisateur du dispositif-client pourrait souhaiter savoir si certains autres services auxquels il s'intéresse particulièrement lui sont ou non accessibles.
Toujours dans le cas des accès mobiles, l'opérateur de l'utilisateur peut également, selon la norme 3GPP TS 24.167, configurer les services qu'il offre et/ou autorise dans le dispositif-client. Mais ceci est par définition une disposition statique : une mise à jour de ces informations session d'enregistrement par session d'enregistrement serait excessivement lourde à mettre en œuvre ; de plus, elle suppose le déploiement d'une infrastructure de configuration, ce qui n'est pas garanti. Surtout, cette liste de services ne tient pas compte des éventuelles limitations que pourrait apporter l'existence de réseaux intermédiaires.
II apparaît, en conclusion, que ces techniques connues, même combinées entre elles, ne sont pas aptes à résoudre le problème dans sa généralité. Notamment, elles ne permettent pas de prendre en compte les restrictions apportées par l'utilisation d'un réseau intermédiaire qui serait techniquement incapable de fournir certains services, ou qui n'autoriserait pas certains services, et ne permettent donc pas à un réseau-opérateur de savoir quels services il peut effectivement fournir à un dispositif-client appartenant à ce réseau-opérateur, parmi les services souhaités par l'utilisateur de ce dispositif-client.
La présente invention concerne donc un procédé de détermination d'une liste de services pour l'utilisateur d'un dispositif-client appartenant à un réseau-opérateur, ledit réseau-opérateur mettant en œuvre le protocole de contrôle de session SIP. Ledit procédé est remarquable en ce qu'il comprend les étapes suivantes : - ledit dispositif-client insère dans une requête d'enregistrement auprès du réseau-opérateur une liste de services qu'il a les moyens techniques de fournir,
- le cas échéant, chaque réseau intermédiaire utilisé pour mettre en relation le dispositif client avec le réseau-opérateur transmet ladite requête d'enregistrement vers ledit réseau-opérateur après y avoir supprimé ou marqué, dans ladite liste de services, tous les services que ledit réseau intermédiaire n'a pas les moyens techniques de fournir et/ou pour lesquels le réseau intermédiaire ne possède pas d'accord d'usage avec l'opérateur du réseau amont et/ou aval auquel il est connecté, et
- le réseau-opérateur obtient une liste, dite liste définitive, en extrayant de la liste de services contenue dans la requête d'enregistrement reçue ceux d'entre eux auxquels l'utilisateur du dispositif-client a droit, compte tenu de sa souscription auprès du réseau-opérateur, parmi les services que le réseau-opérateur a les moyens techniques de fournir.
Ainsi, la présente invention propose la transmission, lors d'une requête d'enregistrement, de la liste des services disponibles entre un dispositif-client et son réseau-opérateur, et la modification de cette liste, le cas échéant, par les différents réseaux SIP traversés. Le réseau- opérateur peut ainsi prendre connaissance de l'ensemble des services effectivement disponibles et autorisés de bout en bout.
Selon des caractéristiques particulières, ledit procédé comprend ensuite les étapes suivantes :
- ledit réseau-opérateur insère ladite liste définitive dans une réponse à ladite requête d'enregistrement, et
- ladite réponse est transmise sans modification de la liste définitive audit dispositif-client via, le cas échéant, lesdits réseaux intermédiaires. Grâce à ces dispositions, l'utilisateur du dispositif-client et, le cas échéant, les réseaux intermédiaires, peuvent eux aussi prendre connaissance de la liste des services auxquels cet utilisateur peut effectivement accéder. Ainsi, lors d'une requête de service subséquente (par exemple une requête de type SIP INVITE ou SIP SUBSCRIBE), l'utilisateur du dispositif-client se limitera avantageusement à demander la fourniture de services choisis parmi ceux auxquels il peut effectivement accéder.
Corrélativement, l'invention concerne un dispositif de détermination d'une liste de services dans un réseau SIP, dit premier réseau, caractérisé en ce qu'il possède des moyens pour :
- recevoir, de la part d'un dispositif-client ou d'un réseau SIP, dit deuxième réseau, auquel ledit premier réseau est connecté, une requête d'enregistrement auprès du réseau-opérateur dudit dispositif-client contenant une liste de services, et
- modifier ladite liste de services en y supprimant ou marquant, le cas échéant, tous les services que ledit premier réseau n'a pas les moyens techniques de fournir et/ou pour lesquels les opérateurs du premier réseau et dudit deuxième réseau n'ont pas établi d'accord d'usage mutuel.
Selon des caractéristiques particulières, ledit dispositif possède en outre des moyens pour transmettre à un réseau SIP, dit troisième réseau, auquel ledit premier réseau est connecté, ladite requête d'enregistrement après y avoir supprimé ou marqué dans ladite liste modifiée, le cas échéant, tous les services pour lesquels les opérateurs du premier réseau et dudit troisième réseau n'ont pas établi d'accord d'usage mutuel.
Selon un autre aspect, l'invention concerne un serveur de commande de session comprenant un dispositif tel qu'exposé succinctement ci-dessus. Selon le même aspect, l'invention concerne un serveur d'interconnexion comprenant un dispositif tel qu'exposé succinctement ci-dessus.
Les avantages offerts par ces dispositifs et ces serveurs 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 détermination d'une liste de services 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 les services accessibles, selon l'état de l'art, à un utilisateur connecté à son réseau-opérateur via deux réseaux intermédiaires,
- la figure 2 représente schématiquement la structure d'un réseau
IMS, et
- la figure 3 représente, selon un mode de réalisation de l'invention, un procédé de détermination des services effectivement accessibles à un utilisateur connecté à son réseau-opérateur via deux réseaux intermédiaires. 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 RO peuvent par exemple 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 d'un dispositif-client UE 10, qui peut échanger à travers ce réseau RO des flux multimédias et des signaux de contrôle de session conformes au protocole SIP, notamment avec un autre dispositif- client UE 1 1 , les dispositifs-clients 10 et 1 1 s'étant au préalable enregistrés auprès du réseau RO.
Le dispositif-client 10, 1 1 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, ou encore un logiciel sur un PC ou sur un smartphone, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel.
Comme le montre la figure 2, ce système de fourniture de services multimédia s'appuie sur un réseau RO conforme à l'architecture IMS définie au 3GPP, et qui comprend :
• une infrastructure de transport IP (non représentée) ;
• un ou plusieurs serveurs d'appel l/S-CSCF (pour la combinaison d'une fonction « Interrogating-Call Server Control Function » et d'une fonction « Serving-Call Server Control Function » dans le même serveur) ; un serveur d'appel l/S-CSCF 22 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau RO ; en effet, pour qu'un tel dispositif puisse bénéficier des services fournis par ce réseau, ce dispositif doit, sauf exceptions (cas de certains appels d'urgence) s'enregistrer auprès du serveur l/S-CSCF 22 ; 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 et de téléphonie TAS 27, ainsi que le routage en direction d'autres terminaux gérés par le même réseau IMS (comme par exemple le dispositif-client 1 1 ) et le routage de la signalisation entre ce réseau IMS RO et d'autres réseaux (non-représentés) ;
un (ou plusieurs) serveur(s) P-CSCF (pour « Proxy - Call Session Control Function » signifiant « Fonction de Commande de Session d'Appel Proxy ») ; le serveur P-CSCF 28 est le point de contact SIP du dispositif-client 1 1 dans le réseau IMS RO ; ainsi, toute la signalisation SIP échangée entre le dispositif-client 1 1 et le serveur d'appel l/S-CSCF 22 passe par ce serveur P-CSCF 28 ;
un ou plusieurs serveurs de base de données de type HSS, mentionné ci-dessus ; un serveur HSS 24 contient le profil de l'utilisateur du dispositif-client 10 en termes de données d'authentification, de localisation et de services souscrits ;
un (ou plusieurs) serveur(s) IBCF 33 ; comme mentionné ci-dessus, le serveur IBCF 33 est situé à la bordure du réseau IMS, et met en œuvre les traitements spécifiques nécessaires, le cas échéant, pour réaliser une interconnexion (non représentée) avec un autre réseau SIP ;
un (ou plusieurs) serveur(s) de messagerie vocale VM 25 ; le serveur VM 25 permet le dépôt d'un message vocal par un appelant tel que le dispositif-client 1 1 , lorsque le dispositif-client 10 appelé ne peut prendre l'appel ;
un (ou plusieurs) serveur(s) de présence PS 26 ; le serveur PS 28 gère la souscription du dispositif-client 10 aux événements de présence que l'utilisateur de ce terminal souhaite surveiller, et notifie le terminal lors de l'occurrence de ces événements ; et • un (ou plusieurs) serveur(s) de téléphonie TAS 27 ; un serveur TAS gère les services téléphoniques auxquels l'utilisateur du dispositif- client 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, les serveurs de présence PS 26 et les serveurs de téléphonie TAS 27 sont des exemples de ce que l'on appelle des « serveurs d'applications » (« application servers » ou AS en anglais).
La présente invention concerne un réseau-opérateur SIP RO et, le cas échéant, le ou les réseau(x) intermédiaire(s) SIP (RI 1 , RI2, et ainsi de suite) traversé(s) par une requête d'enregistrement émise par un dispositif-client 10 à destination du réseau-opérateur RO auquel ce dispositif-client 10 appartient. Au moins l'un de ces réseaux pourra avantageusement être un réseau de type IMS.
On va décrire à présent, en référence à la figure 2 et à la figure 3, un mode de réalisation de l'invention. On a représenté sur cette figure 3 une situation analogue à celle décrite ci-dessus en référence à la figure 1 , et l'on utilisera ci-dessous des notations analogues.
Lors d'une étape E1 , un dispositif-client T, 10 initie une procédure d'enregistrement auprès de son réseau-opérateur RO. Pour ce faire, il émet une requête d'enregistrement SIP REGISTER, et il y insère une liste de services qu'il a les moyens de fournir (et que l'utilisateur U du dispositif-client T, 10 souhaite pouvoir utiliser tant qu'il restera enregistré).
Lors d'une étape E2, cette requête d'enregistrement est reçue dans un réseau intermédiaire RI 1 par un P-CSCF 29, qui supprime dans ladite liste les services que le réseau RI 1 n'a pas les moyens techniques de fournir (la liste des services que le réseau RI 1 a les moyens de fournir pouvant par exemple être configurée statiquement dans tous les serveurs P-CSCF du réseau RI 1 ) ; en variante, le réseau intermédiaire RI 1 peut préserver la liste reçue, mais y ajouter une indication comprenant son identifiant de réseau et ceux des services avec lesquels il n'est pas compatible ; cette seconde variante (en supposant qu'elle soit appliquée par tous les réseaux-intermédiaires) permet au réseau-opérateur RO d'avoir connaissance de la liste initiale demandée par le dispositif-client et de déterminer quel réseau intermédiaire particulier est à l'origine d'une restriction particulière. Puis le serveur P-CSCF 29 transmet la requête à un IBCF 31 du réseau RI 1 assurant l'interconnexion avec un réseau intermédiaire RI 2 permettant de joindre le réseau-opérateur RO. Cet IBCF 31 peut à son tour modifier la liste en fonction des services négociés avec RI 2, par exemple en se référant à une table donnant, pour chaque réseau interconnecté, la liste des services autorisés.
Lors d'une étape E3, un serveur IBCF 32 (ou plusieurs serveurs IBCF) du réseau RI 2 réitère(nt) ces mêmes opérations en fonction des services que le réseau RI 2 a les moyens de fournir, des services négociés avec le réseau RI 1 et des services négociés avec RO, avant de transmettre la requête à un serveur IBCF 33 du réseau RO. Ce serveur IBCF 33 peut à son tour modifier la liste reçue en fonction des accords d'interconnexion entre RO et RI 2, avant de transmettre la requête à un serveur l-CSCF de RO.
Lors d'une étape E4, ce serveur l-CSCF, au moyen de l'interrogation du HSS 24, sélectionne le S-CSCF qui va gérer l'enregistrement du dispositif-client T. Ce S-CSCF modifie à son tour la liste en fonction des services que le réseau-opérateur RO a les moyens techniques de fournir. Enfin, le réseau-opérateur RO obtient une liste, dite liste définitive, en extrayant de la liste de services ainsi obtenue ceux d'entre eux auxquels l'utilisateur U du dispositif-client T, 10 a droit compte tenu de sa souscription auprès du réseau-opérateur RO.
Lors d'une étape E5, le réseau-opérateur RO insère cette liste définitive dans une réponse 200 OK à la requête REGISTER. Lors des étapes E6 et El, cette réponse 200 OK est transmise, sans modification de la liste définitive, au dispositif-client T, 10 via les réseaux intermédiaires RI2, puis RM .
Somme toute, l'ensemble des étapes E1 à E4 permet au réseau- opérateur RO d'acquérir, au sein de la liste des services que le dispositif- client T, 10 a les moyens techniques de fournir, ceux qui sont en outre compatibles avec les réseaux intermédiaires. L'ensemble des étapes E5 à E7 permet au dispositif-client T, 10, et éventuellement aux réseaux intermédiaires, de découvrir eux aussi la liste des services effectivement accessibles à cet utilisateur U tant qu'il restera enregistré.
Selon des caractéristiques particulières, on peut, pour mettre en œuvre la présente invention, étendre l'utilisation, définie par le 3GPP, des identifiants de services IMS appelés « IMS Communication Service Identifiers » (ICSI). Selon la norme 3GPP, ces identifiants de services sont insérés par un dispositif-client dans une requête SIP en tant que paramètres associés à l'adresse du dispositif-client, et sont véhiculés sans modification jusqu'au réseau-opérateur, qui les réinsère inchangés dans sa réponse 200 OK. L'extension selon la présente invention consiste à permettre l'intervention des réseaux intermédiaires sur cette liste d'identifiants de services, et à prévoir que le réseau-opérateur RO renvoie au dispositif-client T, 10 la liste des services auxquels ce dernier peut effectivement accéder.
Selon d'autres caractéristiques particulières, on définit de nouveaux en-têtes SIP dédiés à la détermination d'une liste de services selon l'invention (cette liste pouvant, en particulier, prendre la forme d'une liste d'identifiants ICSI) ; nous désignerons ci-après ces nouveaux en-têtes SIP par « P-Requested-Services » et « P-Supported-Services ». Dans ce cas, par exemple dans le mode de réalisation décrit ci-dessus : - le dispositif-client T, 10 insère un en-tête P-Requested-Services dans la requête SIP REGISTER avec la liste des services qu'il a les moyens techniques de fournir ;
- chaque réseau intermédiaire RM , RI 2 relaie cet en-tête en y supprimant ou marquant les identifiants des services non compatibles (en raison d'une inaptitude technique ou d'une absence d'accords ad hoc) ;
- le réseau-opérateur RO compare la liste reçue à la liste des services auquel le dispositif-client T, 10 a droit parmi les services que le réseau-opérateur RO a les moyens de fournir, et retourne le sous-ensemble commun au moyen de l'en-tête P-Supported- Services du 200 OK REGISTER ; et
- les réseaux intermédiaires RM , RI 2 relaient cet en-tête sans le modifier.
L'invention peut être mise en œuvre au sein des nœuds, par exemple des serveurs de commande de session ou des serveurs d'interconnexion, 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 détermination d'une liste de services 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 détermination d'une liste de services 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 tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais).
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 détermination d'une liste de services selon l'invention.

Claims

R E V E N D I C A T I O N S
1 . Procédé de détermination d'une liste de services pour l'utilisateur (U) d'un dispositif-client (T, 10) appartenant à un réseau- opérateur (RO), ledit réseau-opérateur (RO) mettant en œuvre le protocole de contrôle de session SIP, caractérisé en ce qu'il comprend les étapes suivantes :
- ledit dispositif-client (T, 10) insère (E1 ) dans une requête d'enregistrement auprès du réseau-opérateur (RO) une liste de services qu'il a les moyens techniques de fournir,
- le cas échéant, chaque réseau intermédiaire (RM , RI2) utilisé pour mettre en relation le dispositif client (T, 10) avec le réseau- opérateur (RO) transmet (E2, E3) ladite requête d'enregistrement vers ledit réseau-opérateur (RO) après y avoir supprimé ou marqué, dans ladite liste de services, tous les services que ledit réseau intermédiaire (RM , RI2) n'a pas les moyens techniques de fournir et/ou pour lesquels le réseau intermédiaire (RM , RI2) ne possède pas d'accord d'usage avec l'opérateur du réseau amont et/ou aval auquel il est connecté, et
- le réseau-opérateur (RO) obtient une liste, dite liste définitive, en extrayant (E4) de la liste de services contenue dans la requête d'enregistrement reçue ceux d'entre eux auxquels l'utilisateur (U) du dispositif-client (T, 10) a droit, compte tenu de sa souscription auprès du réseau-opérateur (RO), parmi les services que le réseau- opérateur (RO) a les moyens techniques de fournir.
2. Procédé de détermination d'une liste de services selon la revendication 1 , caractérisé en ce que ladite liste de services est insérée dans un en-tête SIP dédié (P-Requested-Services).
3. Procédé de détermination d'une liste de services selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend ensuite les étapes suivantes :
- ledit réseau-opérateur (RO) insère (E5) ladite liste définitive dans une réponse à ladite requête d'enregistrement, et
- ladite réponse est transmise (E6, E7) sans modification de la liste définitive audit dispositif-client (T, 10) via, le cas échéant, lesdits réseaux intermédiaires (RI2, RM ).
4. Procédé de détermination d'une liste de services selon la revendication 3, caractérisé en ce que ladite liste définitive est insérée dans un en-tête SIP dédié (P-Supported-Services).
5. Procédé de détermination d'une liste de services selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite liste de services est constituée par une liste d'identifiants de services « IMS Communication Service Identifiers » (ICSI).
6. Procédé de détermination d'une liste de services selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit réseau- opérateur (RO) est un réseau IMS.
7. Dispositif de détermination d'une liste de services dans un réseau SIP, dit premier réseau, caractérisé en ce qu'il possède des moyens pour :
- recevoir, de la part d'un dispositif-client (T, 10) ou d'un réseau SIP, dit deuxième réseau, auquel ledit premier réseau est connecté, une requête d'enregistrement auprès du réseau-opérateur (RO) dudit dispositif-client (T, 10) contenant une liste de services, et
- modifier ladite liste de services en y supprimant ou marquant, le cas échéant, tous les services que ledit premier réseau n'a pas les moyens techniques de fournir et/ou pour lesquels les opérateurs du premier réseau et dudit deuxième réseau n'ont pas établi d'accord d'usage mutuel.
8. Dispositif de détermination d'une liste de services selon la revendication 7, caractérisé en ce qu'il possède en outre des moyens pour transmettre à un réseau SIP, dit troisième réseau, auquel ledit premier réseau est connecté, ladite requête d'enregistrement après y avoir supprimé ou marqué dans ladite liste modifiée, le cas échéant, tous les services pour lesquels les opérateurs du premier réseau et dudit troisième réseau n'ont pas établi d'accord d'usage mutuel.
9. Dispositif de détermination d'une liste de services selon la revendication 7 ou la revendication 8, caractérisé en ce que ledit premier réseau est un réseau IMS.
10. Serveur de commande de session (P-CSCF, S-CSCF), caractérisé en ce qu'il comprend un dispositif selon l'une quelconque des revendications 7 à 9.
1 1 . Serveur d'interconnexion (IBCF, SBC, ISBC), caractérisé en ce qu'il comprend un dispositif selon l'une quelconque des revendications 7 à 9.
12. 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 détermination d'une liste de services selon l'une quelconque des revendications 1 à 6.
13. 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 détermination d'une liste de services selon l'une quelconque des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2012/052930 2012-01-03 2012-12-13 Procede dynamique de determination d'une liste de services dans un reseau sip WO2013102716A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP12815740.1A EP2801178B1 (fr) 2012-01-03 2012-12-13 Procédé dynamique de détermination d'une liste de services dans un réseau sip
US14/370,161 US10608898B2 (en) 2012-01-03 2012-12-13 Dynamic method for determining a list of services in an SIP network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1250050 2012-01-03
FR1250050A FR2985404A1 (fr) 2012-01-03 2012-01-03 Procede dynamique de determination d'une liste de services dans un reseau sip

Publications (1)

Publication Number Publication Date
WO2013102716A1 true WO2013102716A1 (fr) 2013-07-11

Family

ID=47559552

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052930 WO2013102716A1 (fr) 2012-01-03 2012-12-13 Procede dynamique de determination d'une liste de services dans un reseau sip

Country Status (4)

Country Link
US (1) US10608898B2 (fr)
EP (1) EP2801178B1 (fr)
FR (1) FR2985404A1 (fr)
WO (1) WO2013102716A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090093241A1 (en) * 2007-10-05 2009-04-09 Infineon Technologies Ag Method and device for communication setup

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060098624A1 (en) * 2004-11-10 2006-05-11 Morgan David P Using session initiation protocol
EP1886421B1 (fr) * 2005-05-06 2018-10-31 Samsung Electronics Co., Ltd. Procede et appareil de notification d'une modification d'informations de service en fonction de l'etat d'une borne dans un systeme de communication sans fil
US7787443B2 (en) * 2005-09-30 2010-08-31 Alcatel-Lucent Usa Inc. Method and apparatus for allowing peering relationships between telecommunications networks
WO2008085201A2 (fr) * 2006-12-29 2008-07-17 Prodea Systems, Inc. Gestion de restauration et de traitement de secours de fichiers dans des emplacements de mémoire distants à l'aide d'un dispositif de passerelle multiservice côté locaux d'abonné
KR20090003007A (ko) * 2007-07-05 2009-01-09 삼성전자주식회사 휴대용 단말기에서 알람 기능 사용방법 및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090093241A1 (en) * 2007-10-05 2009-04-09 Infineon Technologies Ag Method and device for communication setup

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. TISPAN 3, no. V3.5.2, 1 March 2011 (2011-03-01), XP014065520 *
JOACHIM POETZL MARTIN HUELSEMANN DEUTSCHE TELEKOM JEAN-MARIE STUPKA SIEMENS: "Extensions to the Session Initiation Protocol (SIP) for the support of the Call Completion Services for the European Telecommunications Standards Institute; draft-poetzl-sipping-call-completion-02.txt", 20070201, no. 2, 1 February 2007 (2007-02-01), XP015050311, ISSN: 0000-0004 *

Also Published As

Publication number Publication date
US20150229536A1 (en) 2015-08-13
FR2985404A1 (fr) 2013-07-05
EP2801178A1 (fr) 2014-11-12
EP2801178B1 (fr) 2021-01-27
US10608898B2 (en) 2020-03-31

Similar Documents

Publication Publication Date Title
EP1931104B1 (fr) Procédé de contrôle de l'établissement de canaux de communication multimédia
WO2015092278A1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
EP2504982A1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
FR3034608A1 (fr) Procede de priorisation de flux medias dans un reseau de communications
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
WO2011001061A1 (fr) Procede de selection d'une ressource reseau
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
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
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
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
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
EP3583757B1 (fr) Procédé de changement de réseau mobile
WO2017220883A1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
FR3001351A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
WO2012072942A2 (fr) Procede contre la formation de boucles dans les renvois d'appel
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
FR3066872A1 (fr) Procede de controle d' une communication comprenant des transactions multiples
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: 12815740

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2012815740

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14370161

Country of ref document: US