WO2009013441A1 - Procede d'obtention de donnees applicatives - Google Patents

Procede d'obtention de donnees applicatives Download PDF

Info

Publication number
WO2009013441A1
WO2009013441A1 PCT/FR2008/051358 FR2008051358W WO2009013441A1 WO 2009013441 A1 WO2009013441 A1 WO 2009013441A1 FR 2008051358 W FR2008051358 W FR 2008051358W WO 2009013441 A1 WO2009013441 A1 WO 2009013441A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
message
token
session
data
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/FR2008/051358
Other languages
English (en)
Inventor
Philippe Dussaume
Eric Paillet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
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 SA filed Critical France Telecom SA
Publication of WO2009013441A1 publication Critical patent/WO2009013441A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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/14—Session management
    • 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/4541—Directories for service discovery
    • 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/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • 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/14—Session management
    • H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
    • 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
    • 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/56—Provisioning of proxy services
    • 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/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services

Definitions

  • the present invention relates to the field of communication management and more particularly of session in a session server involved in interconnections between at least two communication devices, a session comprising on the one hand constitution information describing the session and session data.
  • Per session we mean, "Session of use”.
  • a usage session differs from a communication session in that it incorporates a notion of service.
  • a communication session is linked to the establishment of a communication between a user and a device to which he is connected.
  • a communication session is closed when the user disconnects from the device.
  • a usage session contains persistent data that remains after the communication session has expired.
  • a session of use can contain several communication sessions, several user identifiers, several service data.
  • the use sessions are for example implemented within the framework of extensions of the telephony / computer coupling in communication networks.
  • the invention relates to the structuring of exchanges with a session server.
  • the present invention relates more particularly to the field of application data transmissions in telecommunication systems, and in particular to the distinction of data within the system.
  • a telecommunication system implementing a method for exchanging session data includes a main communication network, such as a switched telephone network, able to connect a terminal made available to a user with at least a first means of communication implemented by a first client, said upstream client, identified for example as the first recipient of a communication initiated by the user, for example by dialing a predetermined code on a keyboard alphanumeric with which its terminal is equipped.
  • a main communication network such as a switched telephone network
  • This first means of communication could for example be a home voice server capable of receiving from the user a request, for example verbal, and to guide this request, and thus the current communication, to a second means of communication implemented by another client located in a second communication network, said downstream client, which has been identified by the upstream client as providing a service able to satisfy the request made by the user.
  • the term "customer” should be understood here and in the remainder of the narrative to mean an entity that directly or indirectly solicits the resources of another entity to perform a task, a client that can be embodied by an autonomous server, a group of servers, a platform of services or by various elements distributed within various means of communication included in the system.
  • server should be understood here and in the remainder of the narrative to mean an entity that directly or indirectly provides resources (eg, data or service) to another entity to perform a task.
  • a transmission of data between the communication means of a communication system generally induces an identification of these data to ensure that they are transmitted in accordance with the execution of applications. linked to actions initiated by a user or by a system element.
  • the identification of these data is implemented by the implementation of communication sessions, which are used throughout the interactions between a user of a service and the communication means used in the execution of this service.
  • the session mechanism well known to those skilled in the art, makes it possible, particularly in the implementation of "n-third" information systems, to store information in order to allow continuity of service. Such a session is therefore likely to contain a large amount of data. More generally, a session has constitution information and data specific to it. This session data is routed between the different service platforms.
  • a service platform is an entity of the communication network in charge of providing application services to a customer who requests it. Thus, a service platform can implement several application services that will each render one or more services.
  • usage session data (application data and descriptions) are for example routed from the session data server to a service platform by using a so-called “token” mechanism (also known as a network orrelant).
  • token also known as a network orrelant
  • This mechanism was the subject of a new and inventive application-level translation by the inventors and made it possible to obtain a routing mechanism data through an application network correlator.
  • a correlating network can only carry a limited amount of data before becoming obsolete (indeed, such a network correlant with a limited lifetime, beyond which it can no longer be used).
  • the work of the inventors bearing on the correlators application networks have found that the lifetime of such a correlator is the result of a function directly related to the number of calls (or solicitations) of an application platform (such as a voice platform) per second.
  • an application token is coded on sixteen bits (two bytes). This coding thus makes it possible to obtain a token identifier value range of the order of sixty-five thousand.
  • APIs are defined.
  • such a method comprises: a step of reception by a receiving entity of a message requiring so-called application data, sent by an issuing entity, said message including: a typology identifier, designating a predefined message type; information representative of said application data to be obtained; a step of identifying at least one server, said location server, able to locate said application data to obtain according to said representative information and said typology identifier.
  • the method according to the invention makes it possible to identify a location server, within a set of servers of a communication network dedicated to the provision of services, such as those implemented by the applicant, and which can be in the form of Intranet, that is to say, dedicated networks characterized by their use of the IP protocol.
  • a location server is a server that can provide a location of the information sought by the sender server.
  • the sending entity for example a server
  • the receiving entity for example another server
  • the location of an information is therefore realized in a first time by identifying a server that could indicate this information.
  • the receiving entity can identify itself, that is to say that it can declare itself able to render itself the location service.
  • said method comprises, after said identification step, a step of transmitting a second message to said location server, said second message comprising: a second typology identifier defining a type of said second message from at least two predefined types; said information representative of said application data to be located;
  • the method of the invention allows the receiving server to relay the request to a location server that can respond.
  • said method comprises, after said step of transmitting said second message, a second step of receiving a location message, from said location server, said location message comprising at least one representative application address of an entity capable of delivering said application data.
  • the method according to the invention makes it possible to obtain an address, which makes it possible to locate the server whose data one seeks to obtain.
  • said application address comprises at least one input / output interface which is a function of said at least one application processing to be performed.
  • the application address is not a network address, but an address of a service application that can be in charge of performing the service or providing the expected application data. So this is a new approach to the notion of address that can be variable depending the service to be rendered.
  • an application platform that supports two service application can have several application addresses even though it has only one IP address, in the case for example, the use of this protocol.
  • said method comprises, after said second step of receiving said application address: a step of verifying an authorization of said issuing entity to request said application data; an interrogation step of said entity able to supply said application data as a function of said application address when said authorization is granted.
  • the method according to the invention makes it possible to verify that the entities that make the request have the necessary permissions to obtain the application data they require.
  • said message typology comprises types of messages belonging to the group comprising at least: service messages; - notifications; some orders ; queries.
  • the invention makes it possible to perform faster processing of message types falling within the competence of application software modules (which are greedy in terms of memory and use of computing power).
  • application software modules which are greedy in terms of memory and use of computing power.
  • the use of specific fast modules to respond to simple messages makes it possible to reduce the number of instances of the application modules at a given instant and thus to allocate to each instance a larger amount of memory and a CPU time. " longer.
  • such a system comprises: receiving means included in a receiving entity of a message requesting so-called application data, sent by an issuing entity, said message including: a typology identifier, designating a type of message predefined; information representative of said application data to be obtained; identification means of at least one server, said location server, able to locate said application data to obtain according to said representative information and said typology identifier.
  • the invention also relates to a transmission device.
  • a transmission device includes: means for receiving a message requesting application data, said message comprising: a first typology identifier, designating a predefined message type; information representative of said application data to be obtained; identification means of at least one server, said location server, able to locate said application data to obtain according to said representative information and said typology identifier.
  • a transmission device may be in the form of a server, such as a session data server.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, and comprising program code instructions for the computer. execution of the transmission method as described above.
  • FIG. 1 is a block diagram describing the principle of the obtaining method according to the invention
  • Fig. 2 is a sequence diagram showing access of the service applications to the different servers only through a session data server to which they are attached
  • FIG. 3 is a sequence diagram showing direct access of the service applications to the different servers
  • FIG. 4 is a sequence diagram in which service applications have access to the different servers after initial access to a server. own session data server for location of the token;
  • FIG. 1 is a block diagram describing the principle of the obtaining method according to the invention
  • Fig. 2 is a sequence diagram showing access of the service applications to the different servers only through a session data server to which they are attached
  • FIG. 3 is a sequence diagram showing direct access of the service applications to the different servers
  • FIG. 4 is a sequence diagram in which service applications have access to the different servers after initial access to a server. own session data server for location of the token
  • FIG. 1 is a block diagram describing the principle of the obtaining method according to the invention
  • FIG. 5 is a sequence diagram in which service applications have access to the different servers after initial access to a session-specific data server for the location of the token and obtaining it;
  • FIG. 6 is a sequence diagram in which service applications have access to the different servers after initial access to a session-specific data server for the location of the token, the location of the session and the obtaining of these data. through a rights audit;
  • FIG. 7 is a sequence diagram showing an example of a system where the client service applications have direct access to the different servers, as part of a scenario simplified by using URLs and simplified addresses for the tokens, and digital passports.
  • FIG. 8 is a sequence diagram showing an example of a system where the client ASs access the different servers, after initial access via a clean session data server, as part of a simplified Scenario using the Simplified URLs and addresses for tokens, and digital passports;
  • FIG. 9 is a block diagram showing the operation of an active token location server;
  • Fig. 10 is a block diagram showing the operation of a passive token location server;
  • FIG. 11 is a sequence diagram showing an example of a system where the client ASs have direct access to the different servers in the context of a simplified scenario, with a gateway crossing;
  • FIG. 12 is a sequence diagram showing an example of an example of a system where the client ASs access the different servers, after initial access via a clean SDS, to obtain the token, with gateway crossing;
  • the method of the invention allows the search and location of useful information, that is to say the search application data involved in a session of use.
  • data concerning the usage session can be found in many places: in a session data management entity (such as a session data server), obviously since it has The purpose of this is to centralize session data, but also within application services, which can be located in the same service platform as a neighboring application that seeks to obtain the data in question.
  • the session data can be in another communication network than that of the service application that wishes to access it (network of a competing operator for example).
  • the obtaining method according to the invention makes it possible to identify, within the neighboring communication network, the entity that owns and is able to supply the required application data.
  • the context of a usage session may include the following: one or more session data servers hosting the context description of the session of use; one or more servers delivering tokens (uniqueness of the chips on the networks); one or more application servers contributing to this session; one or more servers with which these ASs are registered as clients; one or more servers with which the "Closed Client Group” contributing to this session are registered; one or more servers from which the inter-service data of this session are recorded.
  • tokens uniqueness of the chips on the networks
  • the inventors have proposed to prioritize and distribute the application messages exchanged between the session data servers and the service platforms according to two axes: use of specific application communication channels, for example by defining several IP addresses for the same application server, each of these addresses being used for a particular type of message. It was also proposed to define client software modules, present on the service platforms that can meet certain specific application exchange needs without the need to implement an application service in its entirety. This avoids overloading the service platform by not creating the instance of the service application to perform simple application exchanges.
  • an input-output interface includes, in general:
  • a specific port of this IP address - A client software module that is connected to the IP address / specific port pair.
  • the obtaining method according to the invention takes advantage of these addressing interfaces and the application software modules associated therewith.
  • a communication is established between an entity 10 and an entity 11.
  • the 10 seeks to obtain application data, which are located on an entity in charge of an application processing (not shown).
  • the entity 10 and the entity 11 are located within a communication network comprising a plurality of entities, servers and clients.
  • This message 101 comprises: a typology identifier, defining a type of said message among at least two predefined types (not shown); information representative of said application data to be located (102);
  • the entity 11 identifies 1001, according to said representative information and said typology identifier, a server 12 of the communication network capable of performing said localization.
  • This server 12 is called the location server.
  • the entity l lemet (1002) a second message to the location server 12, the second message 103 comprising: - a second typology identifier, defining a type of said second message (not shown); the representative information 102 of the application data to be located;
  • the various functions of the location servers implementing an embodiment of the obtaining method according to the invention are then presented.
  • the "location server of information of a given nature" token, session, "closed client group", client
  • the location server does not provide the information as such.
  • a client or a server having access to an element of a location server will always obtain, if it has the right, the location of the desired information source, the element contacted instructing to search for location information within the location system in a manner that is transparent to the requester, whether the location information is centrally or distributed hosted, and accessed in a mesh or hierarchical manner.
  • a session data server location server therefore makes it possible to find a session data server, for example when it is not located on the same communication network as the server that wishes to access it.
  • the parameters passed in query of this type of server are: identifier of the author of the request, designation of the session data server or servers concerned.
  • These servers enable the session data servers and client ASs, as well as the location servers and other servers mentioned earlier, to locate the client application servers of the session data servers, i.e. address of the input / output interfaces of the servers from which these clients are registered and able to authenticate them.
  • the parameters passed in query of this type of server are: identifier of the author of the request, designation of the customer (s) concerned. Parameters passed in response: - Addresses of the registration server (s) of the concerned customers.
  • These servers allow the session data servers and client ASs, as well as the aforementioned servers, to locate the "closed client group", that is, to obtain the address of the input / output interfaces.
  • the servers with which these "closed client group” are registered with the list of clients and "closed customer subgroups" belonging to these "Closed Client Group”.
  • Parameters passed in query of this type of server are: identifier of the author of the request, - designation of the "closed group of customers" concerned.
  • Session Location Servers These servers enable session data servers and client ASs to locate sessions, that is, to obtain the I / O interface addresses of the data servers of the session. session where these sessions are recorded.
  • the parameters passed in query of this type of server are: - identifier of the author of the request, designation of the session (s) concerned.
  • These servers allow session data servers and client service applications to locate the tokens, that is, to obtain the address of the I / O interfaces of the servers from which these tokens are registered.
  • the parameters passed in query of this type of server are: identifier of the author of the request, designation of the token (s) concerned. Parameters passed in response: - Addresses of the recording server (s) of the tokens concerned.
  • These servers allow session data servers and client services applications to locate the data, that is, to obtain the address of the input / output interfaces of the servers from which these data are stored.
  • the parameters passed in query of this type of server are: identifier of the author of the request, designation of the data concerned. Parameters passed in response: - Addresses of the data recording server (s) concerned.
  • the following table details the messages corresponding to the requests of the entities (servers) and the responses provided by the destination entities (location servers) of the messages, such as, for example, the request for token localization followed by the token location response.
  • the message column contains the abstract of the messages that will be used in the descriptions of the following figures. It is only a representation. Messages, when implemented may have different formulations.
  • FIG. 2 shows an exemplary sequencing for obtaining application data from a session data server (SDS5) by a client service application (C2) of a session data server.
  • SDS2 itself considered to be a client of the other entities of the network (the SLJ token location server, etc.).
  • the session data server SDS1 intervenes for the provision of the identifier of the sessions associated with the token.
  • the SDS3 session data server is involved in providing the description of the session.
  • the SDS4 session data server is involved in providing data relating to the (closed) client groups.
  • the SDS5 session data server is involved in providing the session application data as such.
  • the messages exchanged are those described in the previous table.
  • the session data server (SDS2) acts as an intermediary of the client (C2) with one of the information location servers (token, session, or "closed client group"), or a server able to deliver this information.
  • the target server does not have to verify that the client is the one that it claims to be and that it has the right to access the system, since it trusts the server (SDS2) that interrogates it, which is the one with which the customer (C2) is registered. It is assumed that, prior to the requests of the service application C2, other service applications have entered data, or have allowed the recording of data within at least some of the SDS1 session data servers, SDS2 , SDS3, SDS4 and SDS5.
  • the exchange space is completely open, and the client can directly access the various servers for locating information and servers holding this information. It is therefore not necessary for the client (C2) to go through the session data server (SDS2) to which it is attached to obtain the information it needs.
  • SDS2 session data server
  • the servers obtain from the session data server (SDS2) where the client (C2) is registered, the permissions (dAC messages and rAC messages) to know if the client (C2) has the necessary permissions to obtain the data it claims.
  • SDS2 session data server
  • the permissions dAC messages and rAC messages
  • this server each time the client (C2) accesses an information location server (token, session, or "closed client group"), or to a server capable of delivering this information, this server must check that the client is the one he claims to be and that he has the right to access the system, obtaining here information from a client location server and the server with which this client is registered.
  • an information location server token, session, or "closed client group”
  • This particular session data server may be a session data server with which this client is registered. It can be unique.
  • this server must verify that the client (C2) is the one he claims to be and has the right to access the system, obtaining this information from a client location server and the server with which this client is registered.
  • the session data server (SDS2) to which the client (C2) initially accesses is used to obtain the location of the token.
  • SDS2 session data server
  • the client (C2) accesses an information location server (session, or "closed client group"), or a server capable of delivering this information this server must verify that the client ( C2) is the one he claims to be and has the right to access the system, obtaining this information from a Client Location Server (SLC) and the server from which this client is registered ( SDS2).
  • SLC Client Location Server
  • the different location servers are thus used both by the session data server (SDS2) and the client (C2) to find the location of information than by the other entities of the network to find, for example, information on the client (C2).
  • session data server SDS2
  • client C2
  • session data server SDS2
  • this server each time the client (C2) accesses an information location server (session, or "closed client group"), or a server capable of delivering this information, this server must check that the client (C2) is the one he claims to be and that he has the right to access the system, obtaining here this information from a client location server (SLC) and the server (SDS2) where this customer is registered.
  • SLC client location server
  • SDS2 server
  • this server Whenever the client (C2) accesses a session location server (SLS) or the session data server capable of delivering the session information (SDS3), this server must verify that the client is the same. it claims to be and has the right to access the system, obtaining this information from a client location server and the server from which that client is registered.
  • SLS session location server
  • SDS3 session data server capable of delivering the session information
  • the information ⁇ issuer identifier> + ⁇ token> may for example be carried by the following fields of the signaling:
  • RTC parameter "context data" within the "request for rerouting" of the Signaling User-PCS (specification France Telecom), in a message “facility" of the protocol D of command call for ISDN access, Web: cookie in a redirect message; VoIP / SIP: header "history info” use of a digital passport type system for storing the validation information of the identification / authentication of the client for his journey with the different servers.
  • the simplification of the addressing leads to a deletion, within the network, of the token localization, session localization and group localization entities.
  • the case is presented in which the SDS2 session data server to which the client C2 initially accesses is used to obtain the identifier of the session associated with the token. This session identifier is then used later to obtain the data of the session of use.
  • This corresponds to the simplification of the case presented in FIG. 5, thanks to the reduction of the address structure.
  • the simplification of the addressing leads to a deletion, within the network, of the token location, session localization, client location and group location entities.
  • a first type which we will describe as active, is able to internally store the information describing the change of form of a token during the crossing of a gateway, without the session data server in charge of the session. be informed. When such a token location server is queried, it is able to return the original token and the session data server carrying the token / session association.
  • a second type of token location server which we will describe as passive, uses the session data server to store the information describing the change of form of a token during the crossing of a gateway. When such a token location server is queried, it is able from the current token to designate the session data server carrying the token / session association. 7.1.3.1.1. Active Token Location Server
  • the active token location server behaves like a session server with reduced functionality and has the following functions: - At the request of an inter-network gateway, receiving a call request on a network and wishing to propagate on another network but for this change some information that constitutes what can be called a "token context", for example:
  • Token or ⁇ J / S association bearer address> + ⁇ Token>, or ⁇ Token type> + ⁇ Token>, network on which the token is received, or ⁇ Address of the last borrowed internetwork gateway> , - call or communication session identifier on the network, "calling" and "called” addresses of the call, call history data (signaling), internally stores the incoming token context, - stores also internally the new token used by the gateway, previously requested by it to a session data server (the SLJ could do this, in another implementation option), associates this new token with the token context and the old token, - finds an address of a bearer of a token / session association with the old token from the current token and the token context previously stored, returns to a customer carrying the new token this address, with the two tokens, so that this client can find the associated session.
  • the gateway "P” informs (904) the token location server "SLJ" that the token j 'is associated with the token context cj', by the message [iCJ (j ', cj')];
  • the gateway "P” requests (905) a token [dJ (1)] for the session data server "SDS 2" for 1 token;
  • the session data server "SDS 2" responds (906) to the token request [rJ (j ")] j" (this token is not then associated with the session S 'because it is used as alias);
  • the passive token location server supposedly unique here, has the following functions:
  • Token or ⁇ J / S association bearer address> + ⁇ Token>, or ⁇ Token type> + ⁇ Token>, network on which the token is received, or ⁇ Address of the last borrowed internetwork gateway> , call or communication session identifier on the network, "calling" and “called” addresses of the call, - call history data (signaling). internally stores the incoming token context, recovers the token context from the stored token, returns to a token-bearing client the token context containing the J / S association bearer session data server address, so that this client can find the associated session.
  • the "SLJ" token location server responds (1007) to the "PFS B" service platform that the bearer of the association of a session is the session data server "SDS1", by the message [rLJ (j ', SDSl)] and can now interrogate it.
  • the inter-network gateways can not carry some information of the token context without modification, but without alteration of the token, they can appeal to the SLJ to keep track of this change and can return to the customer immediately in downstream the correct location information.
  • the SLJ token location server which is the first system affected, must check the rights of the client C2 before being able to respond to it.
  • session location servers and group location servers become useless.
  • the client can access the different servers holding the information only after initial access via a particular session data server with which this client is registered.
  • This session data server can be unique. 7.1.3.2.2.1.
  • Initial access for location of the token In connection with FIG. 12, the SDS2 session data server to which the C2 client initially accesses is used to obtain the location of the token. It is this SDS2 session data server that must contact the SLJ to obtain the location of the token, for example by indicating the network on which the client C2 has received and the network parameters (start and end addresses, or information of history for example) and that the client has retransmitted.
  • the session data server SDS2 to which the client C2 has initially accessed is used to obtain the identifier of the session associated with the token, the location of the a token being searched by the home SDS2 session data server which must contact the SLJ token location server to obtain the location of the token, for example by indicating the network on which the client has received and the network parameters received (addresses start and finish, or history information for example) and that the client has relayed.
  • a simplified architecture of a session data server according to the invention is presented. It comprises a memory 141, and a processing unit 140 equipped with a microprocessor, which is controlled by a computer program (or application) 142.
  • the processing unit 140 receives as input, via an interface module. network entry 143, responses (addresses or data) and notifications 144.
  • This data is transmitted via a network output interface module 145 to the devices of the communication network which are responsible for it.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de transmission de données, dans le cadre d'une communication établie entre au moins deux entités. Selon l'invention, un tel procédé comprend : une étape de réception par une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : - un identifiant de typologie, désignant un type de message prédéfini; une information représentative desdites données applicatives à obtenir; une étape d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.

Description

Procédé d'obtention de données applicatives
La présente invention se rapporte au domaine de la gestion de communication et plus particulièrement de session dans un serveur de session partie prenante à des interconnexions entre au moins deux dispositifs de communication, une session comprenant d'une part des informations de constitution décrivant la session et des données de session.
Par session, on entend, « Session d'usage ». Une session d'usage se différencie d'une session de communication par le fait qu'elle intègre une notion de service. Pour sa part une session de communication est liée à l'établissement d'une communication entre un utilisateur et un dispositif auquel il est connecté. Ainsi, une session de communication est fermée quand l'utilisateur se déconnecte du dispositif. Au contraire, une session d'usage contient des données persistantes, qui subsistent après que la session de communication ait expiré. Ainsi une session d'usage peut contenir plusieurs sessions de communication, plusieurs identifiants d'utilisateurs, plusieurs données de services.
Les sessions d'usage sont par exemple mises en œuvre dans le cadre d'extensions du couplage téléphonie/informatique dans des réseaux de communication. L'invention concerne la structuration des échanges avec un serveur de session. La présente invention se rapporte plus particulièrement au domaine des transmissions de données applicatives dans des systèmes de télécommunication, et notamment sur la distinction de données au sein du système.
Dans l'état actuel de la technique, un système de télécommunication mettant en œuvre un procédé d'échange de données de session inclut un réseau de communication principal, tel un réseau téléphonique commuté, apte à mettre en relation un terminal mis à disposition d'un utilisateur avec au moins un premier moyen de communication mis en oeuvre par un premier client, dit client amont, identifié par exemple comme premier destinataire d'une communication qu'aura initiée l'utilisateur, par exemple en composant un code prédéterminé sur un clavier alphanumérique dont est muni son terminal. Ce premier moyen de communication pourra par exemple être un serveur vocal d'accueil apte à recevoir de la part de l'utilisateur une requête, par exemple verbale, et à orienter cette requête, et donc la communication en cours, vers un deuxième moyen de communication mis en oeuvre par un autre client situé au sein d'un second réseau de communication, dit client aval, lequel aura été identifié par le client amont comme fournissant un service apte à satisfaire la requête formulée par l'utilisateur. Le terme "client" doit être compris ici et dans la suite de l'exposé comme désignant une entité qui sollicite directement ou indirectement les ressources d'une autre entité pour exécuter une tâche, un client pouvant être matérialisé par un serveur autonome, par un groupe de serveurs, une plateforme de services ou par divers éléments répartis au sein de divers moyens de communication inclus dans le système. Le terme « serveur » doit être compris ici et dans la suite de l'exposé comme désignant une entité qui fournit directement ou indirectement des ressources (par exemple données ou service) à une autre entité pour exécuter une tâche.
Une transmission de données entre les moyens de communication d'un système de communication, tels ceux mis en œuvre par la demanderesse, induit généralement une identification de ces données afin de s'assurer qu'elles sont transmises conformément à l'exécution d'applications liées à des actions initiées par un utilisateur ou par un élément du système. L'identification de ces données est mise en œuvre par l'implémentation de sessions de communication, lesquelles sont utilisées tout au long des interactions entre un utilisateur d'un service et les moyens de communication utilisés dans l'exécution de ce service. Le mécanisme de session, bien connu de l'homme du métier, permet, notamment dans la mise en œuvre de systèmes d'information « n-tiers », de conserver des informations afin de permettre une continuité de service. Une telle session est donc susceptible de contenir un important volume de données. Plus généralement, une session possède des informations de constitution et des données qui lui sont propres. Ces données de session sont routées entre les différentes plateformes de services. Une plateforme de service est une entité du réseau de communication en charge de la fourniture de services applicatifs à un client qui en fait la demande. Ainsi, une plateforme de services peut mettre en œuvre plusieurs services applicatifs qui vont chacun rendre un ou plusieurs services.
Des techniques communément employées de l'art antérieur appliquées à ces données de session d'usage permettent de réaliser un échange applicatif de données en deux étapes. En effet, les données applicatives des sessions d'usage contiennent de nombreux paramètres et de nombreuses informations de sorte que l'échange des données d'une session d'usage entre un serveur de données de session (qui gère ces données de manière centralisée) et des plateformes de services (qui ont successivement besoin de ces données) est difficilement réalisable d'un seul tenant.
Ainsi, il a été développé un mécanisme permettant d'échanger des données par le biais d'une première phase d'interrogation, par la plateforme de service, d'un serveur de données de session qui permet à la plate forme de demander la structure de la session d'usage puis au moins une deuxième phase de transmission des données de la session en fonction des besoins de la plateforme de service. Ainsi, les échanges entre les plateformes de services et le serveur de données de session sont réduits en fonction des besoins des plateformes.
Les travaux des inventeurs ont cependant permis de découvrir que ces transferts applicatifs en deux phases ne résolvent pas tous les problèmes liés à des échanges de données trop volumineuses.
En effet, les données de session d'usage (données applicatives et descriptions) sont par exemple routées du serveur de données de session à une plateforme de services en utilisant un mécanisme dit de « jeton » (également appelé c orrélant réseau).
Un tel mécanisme est déjà mis en œuvre au sein de protocoles réseaux (« anneau à jeton » de l'anglais « token ring ») et fonctionne sur les couches Physique et Liaison du modèle OSI.
Ce mécanisme a fait l'objet d'une transposition nouvelle et inventive au niveau applicatif par les inventeurs et a permis d'obtenir un mécanisme de routage des données par le biais d'un corrélant réseau applicatif. Or un tel corrélant réseau ne permet de transporter qu'une quantité limitée de données avant de devenir caduque (en effet, un tel corrélant réseau à une durée de vie limitée, au delà de laquelle il ne peut plus être utilisé). Ainsi, les travaux des inventeurs portants sur les corrélants réseaux applicatifs ont permis de découvrir que la durée de vie d'un tel corrélant est le résultat d'une fonction directement liée au nombre d'appels (ou de sollicitations) d'une plateforme applicative (telle qu'une plateforme vocale) par seconde. En effet, un jeton applicatif est codé sur seize bits (soit deux octets). Ce codage permet donc d'obtenir une plage de valeur d'identifiant de jeton de l'ordre de soixante cinq mille. Ainsi, si l'on considère une plateforme de test qui reçoit environ cinquante appels par secondes, la durée de vie d'un corrélant est de mille trois cent secondes, soit environ vingt et une minutes. Or une telle fréquence d'appel n'est valable que pour une plateforme de test. En production, une plateforme de ce type peut aisément recevoir jusqu'à cinq cent sollicitations par secondes. On comprend donc l'absolue nécessité de réaliser des traitements rapides et efficaces.
De plus, en l'état actuel, la structuration des échanges en deux phases (structure puis données) combinée à un échange sous la forme de jeton entraîne une complexité importante, tant au niveau des plateformes de service que du serveur de données de sessions.
Du point de vue des plateformes de services, la gestion des données de session et la gestion des échanges de messages pèse inutilement sur les performances globales de la plateforme et entraîne des retards de mise en œuvre des services en tant que tels. En effet, les missions dédiées aux plateformes de services sont bien d'exécuter des services en tant que tels et non de gérer la pertinence de données en provenance d'un serveur central, d'en déduire le traitement à effectuer ou encore de gérer un stock de jetons prêt à être attribué à telle ou telle session d'usage liée à un utilisateur.
Afin de décrire les protocoles d'échanges de message entre les serveurs de données de session et leurs clients, du point de vue de ces clients, et de faciliter le travail des développeurs informatiques sur les plates-formes de services pour la gestion applicative de ces échanges, des API sont définies.
Cependant, la richesse des protocoles d'échanges de message entre les serveurs de données de session et leurs clients, et leur nécessaire prise en compte des aléas sur des réseaux inter-applicatifs ouverts, rendent malgré tout la gestion des échanges complexe pour les plates-formes de services.
L'invention offre une solution qui ne présente pas les inconvénients de l'art antérieur, grâce à un procédé de transmission de données, dans le cadre d'une communication établie entre au moins deux entités. Selon l'invention, un tel procédé comprend : une étape de réception par une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : un identifiant de typologie, désignant un type de message prédéfini ; une information représentative desdites données applicatives à obtenir ; une étape d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
Ainsi, le procédé selon l'invention permet d'identifier un serveur de localisation, au sein d'un ensemble de serveurs d'un réseau de communication dédié à la fourniture de services, tels que ceux mis en œuvre par la demanderesse, et qui peuvent se présenter sous la forme d'Intranet, c'est-à-dire de réseaux dédiés caractérisés par leur utilisation du protocole IP. Un serveur de localisation est un serveur qui peut fournir une localisation de l'information recherchée par le serveur émetteur. L'entité émettrice (par exemple un serveur) cherchant à obtenir des données contacte donc l'entité réceptrice (par exemple un autre serveur) pour obtenir l'information. La localisation d'une information est donc réalisée dans un premier temps par l'identification d'un serveur qui pourrait indiquer cette information. Selon un mode de mise en œuvre particulier de l'invention, l'entité réceptrice peut s'identifier elle-même, c'est-à-dire qu'elle peut se déclarer apte à rendre elle-même le service de localisation. Selon un mode de réalisation particulier de l'invention, ledit procédé comprend, postérieurement à ladite étape d'identification, une étape d'émission d'un deuxième message à destination dudit serveur de localisation, ledit deuxième message comprenant : un deuxième identifiant de typologie, définissant un type dudit deuxième message parmi au moins deux types prédéfinis ; ladite information représentative des dites données applicatives à localiser ;
Ainsi, après avoir identifié un serveur pouvant répondre au besoin exprimé par le serveur émetteur, le procédé selon l'invention permet au serveur récepteur de relayer la demande à un serveur de localisation qui peut lui répondre.
Selon une caractéristique particulière de l'invention ledit procédé comprend, postérieurement à ladite étape d'émission dudit deuxième message, une deuxième étape de réception d'un message de localisation, en provenance dudit serveur de localisation, ledit message de localisation comprenant au moins une adresse applicative représentative d'une entité apte à délivrer lesdites données applicatives.
Ainsi, le procédé selon l'invention permet d'obtenir une adresse, qui permet de localiser le serveur dont on cherche à obtenir des données.
Selon un mode de réalisation particulier de l'invention, ladite adresse applicative comprend au moins une interface d'entrée/sortie qui est fonction dudit au moins un traitement applicatif à réaliser.
Ainsi, l'adresse applicative n'est pas une adresse de réseau, mais bien une adresse d'un applicatif de service qui peut être en charge de la réalisation du service ou de la fourniture des données applicatives escomptées. Il s'agit donc ici d'une approche nouvelle de la notion d'adresse qui peut être variable en fonction du service à rendre. Ainsi, une plateforme applicative qui supporterait deux applicatif de service peut disposer de plusieurs adresses applicatives alors même qu'elle ne dispose que d'une seule adresse IP, dans le cas par exemple, de l'utilisation de ce protocole. Selon une caractéristique particulière de l'invention, ledit procédé comprend, postérieurement à ladite deuxième étape de réception de ladite adresse applicative : une étape de vérification d'une autorisation de ladite entité émettrice à requérir lesdites données applicatives ; - une étape d'interrogation de ladite entité apte à fournir lesdites données applicatives en fonction de ladite adresse applicative lorsque ladite autorisation est accordée.
Ainsi, le procédé selon l'invention permet de vérifier que les entités qui en font la demande disposent bien des autorisations nécessaires à l'obtention des données applicatives qu'elles requièrent.
Selon un mode de réalisation original de l'invention, ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : des messages de service ; - des notifications ; des commandes ; des requêtes.
Ainsi, l'invention permet de trier les messages en fonction de leur type et de séparer les traitements applicatifs de ceux-ci. Par exemple, lors de la réception d'un message de type « message de service », l'entité qui reçoit ce message peut activer un module logiciel « rapide » pour le traitement de ce message. Par exemple, si l'entité qui reçoit ce message de service est un fournisseur de services, ce fournisseur de services n'est pas obligé de mettre en œuvre un service applicatif pour répondre à ce message, mais peut directement y répondre en activant un module spécifique de réponse à ces messages de service. En d'autres termes, grâce à l'invention, il n'est pas nécessaire, pour une plateforme de service de mettre en œuvre des modules applicatifs lourds et consommateurs de ressources pour répondre à des messages de services simples, concernant notamment les couches applicatives basses. Ainsi, la réponse peut être réalisée dans des temps très courts, qui ne nécessitent pas l'utilisation de plusieurs corrélants réseaux (plusieurs jetons). En conséquence, l'invention permet de réaliser des traitements plus rapides des types de message relevant de la compétence de modules logiciels applicatifs (qui sont gourmands en termes de mémoire et d'utilisation de puissance de calcul). En effet, l'utilisation de modules spécifiques rapides pour répondre à des messages simples permet de diminuer le nombre d'instances des modules applicatifs à un instant donné et donc d'allouer à chaque instance une quantité de mémoire plus importante et un temps « CPU » plus long.
L'invention concerne également un système de transmission de données incluant au moins deux entités.
Selon l'invention, un tel système comprend : des moyens de réception inclus dans une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : - un identifiant de typologie, désignant un type de message prédéfini ; une information représentative desdites données applicatives à obtenir ; des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
L'invention concerne également un dispositif de transmission. Selon l'invention, un tel dispositif inclut : - des moyens de réception d'un message requérant des données applicatives, ledit message comprenant : un premier identifiant de typologie, désignant un type de message prédéfini ; une information représentative desdites données applicatives à obtenir ; des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie. Dans au moins un mode de réalisation particulier de l'invention, un tel dispositif de transmission peut se présenter sous la forme d'un serveur, tel qu'un serveur de données de sessions.
Selon un autre aspect, l'invention concerne également un produit 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, et comprenant des instructions de code de programme pour l'exécution du procédé de transmission tel que décrit précédemment.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 est un diagramme de blocs décrivant le principe du procédé d'obtention selon l'invention ; la figure 2 est un diagramme de séquence présentant un accès des applicatifs de services aux différents serveurs uniquement par le biais d'un serveur de données de session auxquels ils sont attachés ; la figure 3 est un diagramme de séquence présentant un accès direct des applicatifs de services aux différents serveurs ; la figure 4 est un diagramme de séquence dans lequel des applicatifs de services ont un accès aux différents serveurs après un accès initial à un serveur de données de session propre pour la localisation du jeton ; la figure 5 est un diagramme de séquence dans lequel des applicatifs de services ont un accès aux différents serveurs après un accès initial à un serveur de données de session propre pour la localisation du jeton et l'obtention de celui-ci ; la figure 6 est un diagramme de séquence dans lequel des applicatifs de services ont un accès aux différents serveurs après un accès initial à un serveur de données de session propre pour la localisation du jeton, la localisation de la session et l'obtention de ces données, par l'intermédiaire d'une vérification des droits ; la figure 7 est un diagramme de séquence présentant un exemple d'un système où les applicatifs service clients ont un accès direct aux différents serveurs, dans le cadre d'un Scénario simplifiés par utilisation d'URLs et d'adresses simplifiées pour les jetons, et des passeports numériques. - la figure 8 est un diagramme de séquence présentant un exemple d'un système où les AS clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre, dans le cadre d'un Scénario simplifiés par utilisation d'URLs et d'adresses simplifiées pour les jetons, et des passeports numériques ; - la figure 9 est un diagramme de blocs présentant le fonctionnement d'un serveur de localisation de jetons actif ; la figure 10 est un diagramme de blocs présentant le fonctionnement d'un serveur de localisation de jetons passif ; la figure 11 est un diagramme de séquence présentant un exemple d'un système où les AS clients ont un accès direct aux différents serveurs dans le cadre d'un scénario simplifié, avec franchissement de passerelle ; la figure 12 est un diagramme de séquence présentant un exemple d'un exemple d'un système où les AS clients accèdent aux différents serveurs, après un accès initial via un SDS propre, pour l'obtention du jeton, avec franchissement de passerelle ; la figure 13 est un diagramme de séquence présentant un exemple d'un exemple d'un système où les AS clients accèdent aux différents serveurs, après un accès initial via un SDS propre, pour l'obtention du jeton et de la session, avec franchissement de passerelle ; - la figure 14 décrit une architecture simplifiée d'un serveur d'obtention de données applicatives selon l'invention.
Le procédé selon l'invention permet la recherche et la localisation des informations utiles, c'est-à-dire la recherche des données applicatives impliquées dans une session d'usage. Comme cela a déjà été évoqué, des données concernant la session d'usage peuvent se trouver dans de nombreux endroits : dans une entité de gestion de données de session (tel qu'un serveur de données de sessions), bien évidemment puisqu'elle a pour objet la centralisation des données de session, mais également au sein de services applicatifs, qui peuvent être situés dans la même plateforme de service qu'un applicatif voisin cherchant justement à obtenir les données en question.
Dans d'autres cas de figure, les données de session peuvent se trouver dans un autre réseau de communication que celui de l'applicatif de service qui souhaite y accéder (réseau d'un opérateur concurrent par exemple). Le procédé d'obtention selon l'invention permet d'identifier, au sein du réseau de communication voisin, l'entité qui possède et qui est apte à fournir, les données applicatives requises.
Le procédé d'obtention selon l'invention peut être mis en œuvre sur les plates-formes de services (PFS) supportant les applicatifs de services (AS) clients de Serveurs de Données de Sessions (SDS), et sur ces Serveurs de Données de Sessions eux-mêmes ou sur des systèmes additionnels. Les mécanismes particuliers permettant la recherche et la localisation des informations utiles, selon l'invention, peuvent être implémentés sous la forme d'un enrichissement des protocoles déjà définis, eux-mêmes supportés par des dispositifs logiciels et matériels ad hoc.
En effet, dans un espace dédié à aux échanges de données de contexte de session d'usage non pas fermé mais ouvert, où sont gérés ou manipulés des serveur de données de session, des applicatifs de services, des groupes fermés de clients (« Groupe fermé de clients ») regroupant certains de ces applicatifs de services, des jetons, des sessions et des données, ils faut que les acteurs en présence, applicatifs de services et serveur de données de session, soient assurés de pouvoir chercher les informations aux bon endroit, ou de les délivrer à qui de droit.
En première approche, le contexte d'une session d'usage peut mettre en présence les éléments suivants : un ou plusieurs serveurs de données de session hébergeant la description du contexte de la session d'usage ; un ou plusieurs serveurs délivrant des jetons (unicité des jetons sur les réseaux) ; un ou plusieurs serveurs applicatifs contribuant à cette session ; un ou plusieurs serveurs auprès desquels sont enregistrés ces AS en tant que clients ; un ou plusieurs serveurs auprès desquels sont enregistrés les « Groupe fermé de clients » contribuant à cette session ; un ou plusieurs serveurs auprès desquels sont enregistrées les données interservices de cette session. Parallèlement, afin de permettre aux entités de gestion de données de session et applicatifs de services d'accéder aux autres "bonnes" entités de service (serveurs) et entités de gestion de données de session et à ces entités d'authentifier les "bons" clients, applicatifs de services et entités de gestion de données de session, on peut mettre en œuvre un système nouveau de serveurs de localisation de ces éléments, permettant aux acteurs de n'avoir pas à connaître ou mémoriser systématiquement et à priori toutes les adresses nécessaires à la recherche des informations utiles : un ou plusieurs serveurs de localisation des entités de gestion de données de session ; - un ou plusieurs serveurs de localisation des clients ; un ou plusieurs serveurs de localisation des « Groupe fermé de clients » ; un ou plusieurs serveurs de localisation des sessions ; un ou plusieurs serveurs de localisation des jetons ; un ou plusieurs serveurs de localisation des données. Dans un deuxième mode de réalisation de l'invention, on peut préférer une approche différente, et placer l'adresse des entités (qui peuvent être des serveurs) détenant les informations dans l'étiquette même de ces informations, à la façon des URL, pour tout ou partie des ces informations. Ces différentes approches sont décrites ci-après, au travers de quelques scénarios de mise en oeuvre. Parallèlement à la mise en œuvre du procédé de d'obtention des données applicatives selon l'invention, les inventeurs ont proposé de hiérarchiser et de distribuer les messages applicatifs échangés entre les serveurs de données de session et la plateformes de service selon deux axes : l'utilisation de canaux de communications applicatifs spécifiques, par exemple en définissant plusieurs adresses IP pour un même serveur applicatif, chacune de ces adresses étant utilisée pour un type de message particulier. Il a été également proposé de définir des modules logiciels clients, présents sur les plateformes de services qui permettent de répondre à certains besoins d'échanges applicatifs spécifiques sans qu'il soit nécessaire de mettre en œuvre un service applicatif dans son intégralité. On évite ainsi une surcharge de la plateforme de service en ne créant pas l'instance de l'applicatif de service pour réaliser de simples échanges applicatifs.
Ainsi, une interface d'entrée sortie comprend, de manière générale :
Une adresse IP ;
Un port spécifique de cette adresse IP ; - Un module logiciel client qui est connecté au couple adresse IP/port spécifique.
Le procédé d'obtention selon l'invention tire parti de ces interfaces d'adressage et des modules logiciels applicatifs qui y sont associées.
On décrit, en relation avec la figure 1, les étapes du procédé d'obtention selon l'invention : Une communication est établie entre une entité 10 et une entité 11. L'entité
10 cherche à obtenir des données applicatives, qui sont situées sur une entité en charge d'un traitement applicatif (non représenté). L'entité 10 et l'entité 11 sont situées au sein d'un réseau de communication comprenant une pluralité d'entité, des serveurs et des clients.
L'entité 11, en charge d'obtenir les données, reçoit (1000) un message 101 en provenance de l'entité 10 qui demande les données. Ce message 101 comprend : un identifiant de typologie, définissant un type dudit message parmi au moins deux types prédéfinis (non représenté) ; une information représentative des dites données applicatives à localiser (102) ;
L'entité 11 identifie 1001, en fonction de ladite information représentative et dudit identifiant de typologie, un serveur 12 du réseau de communication apte à réaliser ladite localisation. Ce serveur 12 est appelé serveur de localisation.
Par la suite, dans un mode de réalisation de l'invention, l'entité l lemet (1002) un deuxième message à destination du serveur de localisation 12, ce deuxième message 103 comprenant : - un deuxième identifiant de typologie, définissant un type dudit deuxième message (non représenté) ; l'information représentative 102 des données applicatives à localiser ;
On présente par la suite les différentes fonctions des serveurs de localisation mettant en œuvre un mode de réalisation du procédé d'obtention selon l'invention. On appelle « serveur de localisation d'une information d'une nature donnée » (jeton, session, « Groupe fermé de clients », client) un système à même de fournir « l'adresse d'un serveur capable de fournir l'information demandée », quelque soit la structure de ce système, monolithique ou composite, pour des raisons de facilité. Le serveur de localisation ne fourni pas l'information en tant que telle.
De cette façon, on considérera qu'un client ou un serveur ayant accès à un élément d'un serveur de localisation obtiendra toujours, s'il en a le droit, la localisation de la source d'information souhaitée, l'élément contacté se chargeant de rechercher l'information de localisation au sein du système de localisation de façon transparente pour le requérant, que cette l'information de localisation soit hébergée de façon centralisée ou distribuée, et accessible de façon maillée ou hiérarchisée. 1. Serveurs de localisation des serveurs de données de session
Ces serveurs permettent aux serveurs de données de session et aux AS clients de ces serveur de données de session, ainsi qu'aux aux serveurs de localisation et autres serveurs mentionnés précédemment, de localiser un serveur de données de session, c'est-à-dire d'obtenir l'adresse de ses interfaces d'Entrée/Sortie déclinées par services, à savoir requêtes, messages de service et notifications (échanges entre serveur de données de session et clients). Un serveur de localisation de serveur de données de session permet donc de retrouver un serveur de données de session, par exemple lorsque celui-ci n'est pas situé sur le même réseau de communication que le serveur qui souhaite y accéder. Les paramètres passés en interrogation de ce type de serveur sont : identifiant de l'auteur de la requête, désignation du ou des serveurs de données de session concernés.
Paramètres passés en réponse :
Adresses du ou des serveurs de données de session concernés. 2. Serveurs de localisation des clients
Ces serveurs permettent aux serveurs de données de session et aux AS clients, ainsi qu'aux serveurs de localisation et autres serveurs mentionnés précédemment de localiser les serveurs applicatifs clients des serveurs de données de session, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs auprès desquels ces clients sont enregistrés et à même de les authentifier. Les paramètres passés en interrogation de ce type de serveur sont : identifiant de l'auteur de la requête, désignation du ou des clients concernés. Paramètres passés en réponse : - Adresses du ou des serveurs d'enregistrement des clients concernés.
3. Serveurs de localisation des « Groupe fermé de clients »
Ces serveurs permettent aux serveurs de données de session et aux AS clients, ainsi qu'aux serveurs mentionnés précédemment de localiser les « Groupe fermé de clients », c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/S ortie des serveurs auprès desquels ces « Groupe fermé de clients » sont enregistrés avec la liste des clients et des « sous-groupes fermés de clients» membres de ces « Groupe fermé de clients ».
Les paramètres passés en interrogation de ce type de serveur sont : identifiant de l'auteur de la requête, - désignation du ou des « Groupe fermé de clients » concernés.
Paramètres passés en réponse :
Adresses du ou des serveurs d'enregistrement des « Groupes fermés de clients » concernés.
4. Serveurs de localisation des sessions Ces serveurs permettent aux serveurs de données de session et aux AS clients de localiser les sessions, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs de données de session auprès desquels ces sessions sont enregistrées.
Les paramètres passés en interrogation de ce type de serveur sont : - identifiant de l'auteur de la requête, désignation de la ou des sessions concernées.
Paramètres passés en réponse :
Adresses du ou des serveurs de données de session concernés. 5. Serveurs de localisation des jetons
Ces serveurs permettent aux serveurs de données de session et aux applicatifs de services clients de localiser les jetons, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs auprès desquels ces jetons sont enregistrés.
Les paramètres passés en interrogation de ce type de serveur sont : identifiant de l'auteur de la requête, désignation du ou des jetons concernés. Paramètres passés en réponse : - Adresses du ou des serveurs d'enregistrement des jetons concernés.
6. Serveurs de localisation des données
Ces serveurs permettent aux serveurs de données de session et aux applicatifs de services clients de localiser les données, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/S ortie des serveurs auprès desquels ces données sont enregistrées.
Les paramètres passés en interrogation de ce type de serveur sont : identifiant de l'auteur de la requête, désignation du ou des données concernées. Paramètres passés en réponse : - Adresses du ou des serveurs d'enregistrement des données concernés.
7. Description d'un mode de réalisation
On présente ci-après différents modes de mise en œuvre du procédé d'obtention selon l'invention. On présente également des exemples de séquences d'échanges entre les différentes entités de réseau de communication utilisant des systèmes mettant en œuvre le procédé selon l'invention.
Pour des raisons de simplicité dans la description, on n'illustre ici l'utilisation du procédé que pour le cas d'un client recevant un jeton dans la signalisation et cherchant à obtenir les données de la session associée à ce jeton, mais le procédé est également destiné à être mis en œuvre à tous les moments de la relation entre les serveurs de données de sessions et leurs clients, notamment pour la création ou la modification de session ou des droits associés, la définition de groupes fermés de clients, les échanges de notifications ou de messages de service.
7.1. Échanges au sein du système proposé
Le tableau suivant détaille les messages correspondant aux requêtes des entités (serveurs) et aux réponses apportées par les entités destinatrices (serveurs de localisation) des messages, comme par exemple la demande de localisation de jeton suivi de la réponse de localisation de jeton.
La colonne message contient l'abrégé des messages qui seront utilisés lors des descriptions des figures suivantes. Il ne s'agit que d'une représentation. Les messages, lors de leur mise en œuvre pourront avoir des formulations différentes.
Figure imgf000020_0001
Figure imgf000021_0001
7.1.1. Scénarios de base
Dans ces scénarios, on illustre différents modes de mise en œuvre sans optimisation, c'est-à-dire sans qu'il soit mis en œuvre de système de simplification, par exemple de création d'adresse. 7.1.1.1. Exemple d'un système où les serveurs applicatifs clients n'ont qu'un accès indirect aux différents serveurs, chacun via un serveur de données de session donné
Dans un tel mode de mise en œuvre, l'espace d'échange bien qu'ouvert, apparaît comme fermé pour un serveur applicatif client, et ce client ne peut accéder qu'indirectement, via un serveur de données de session auprès duquel il est enregistré, aux différents serveurs de localisation des informations et serveurs détenteurs de ces informations. On présente, en relation avec la figure 2, un exemple de séquencement permettant l'obtention de données applicatives auprès d'un serveur de données de session (SDS5) par un applicatif de service (C2) client d'un serveur de données de session (SDS2) lui-même considéré comme étant un client des autres entités du réseau (le serveur de localisation de jeton SLJ, etc.).
Ici, le serveur de données de session SDSl intervient pour la fourniture de l'identifiant de la sessions associée au jeton. Le serveur de données de session SDS3 intervient pour la fourniture de la description de la session. Le serveur de données de session SDS4 intervient pour la fourniture de données relatives aux groupes (fermé) de client. Le serveur de données de session SDS5 intervient pour la fourniture des données applicatives de session en tant que telles. Les messages échangés sont ceux décrits dans le tableau précédent. Dans cet exemple, le serveur de données de session (SDS2) agit comme un intermédiaire du client (C2) auprès d'un des serveurs de localisation d'une information (jeton, session, ou « groupe fermé de client »), ou d'un serveur à même de délivrer cette information. Le serveur cible n'a pas à vérifier que le client est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, puisqu'il fait confiance au serveur (SDS2) qui l'interroge, qui est celui auprès duquel le client (C2) est enregistré. On suppose que, préalablement aux requêtes de l'applicatif de service C2, d'autres applicatifs de service ont renseigné des données, ou ont permis l'enregistrement de données au sein d'au moins certain des serveurs de données de session SDSl, SDS2, SDS3, SDS4 et SDS5.
Tous les échanges doivent passer par le serveur de données de session
(SDS2) de rattachement utilisé, quelque soit le volume des données. Mais le protocole « client/serveur de données de session » reste simple, toute la problématique de la localisation des données étant gérée par le serveur de données de session.
Les références utilisées dans les figures 3 à 8, 11, 12 et 13, ainsi que les hypothèses préalables de renseignement de données sont les mêmes que dans cette figure 2.
7.1.1.2. Exemple d'un système où les serveurs applicatifs clients ont un accès direct aux différents serveurs
Dans un tel mode de mise en œuvre, l'espace d'échange est totalement ouvert, et le client peut accéder directement aux différents serveurs de localisation des informations et serveurs détenteurs de ces informations. Il n'est donc pas nécessaire, que le client (C2) passe par le serveur de données de session (SDS2) auquel il est attaché pour obtenir les informations dont il a besoin.
On présente, en relation avec la figure 3, un exemple de séquencement des échanges au niveau applicatif. Les rôles des différents serveurs sont les mêmes que dans la figure 2. Dans cet exemple, les serveurs obtiennent auprès du serveur de données de session (SDS2) où le client (C2) est enregistré, les autorisations (messages dAC et messages rAC) permettant de savoir si le client (C2) dispose des autorisations nécessaires à l'obtention des données qu'il réclame.
Ainsi, à chaque fois que le client (C2) accède à un serveur de localisation d'une information (jeton, session, ou « Groupe fermé de clients »), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients et du serveur auprès duquel ce client est enregistré.
7.1.1.3. Exemples d'un système où les serveurs applicatifs clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre
Dans un tel mode de mise en œuvre, l'espace d'échange est ouvert, mais la navigation d'un serveur applicatif client (C2) en son sein est pilotée de manière à ce que ce client ne puisse accéder aux différents serveurs détenteurs des informations qu'après un accès initial via un serveur de données de session particulier (SDS2). Des exemples de séquencement sont présentés en relation avec les figures 4 et 5. Les rôles des différents serveurs sont les mêmes que dans la figure 2.
Ce serveur de données de session particulier (SDS2) peut être un serveur de données de session auprès duquel ce client est enregistré. Il peut être unique.
Ici aussi, à chaque fois que le client accède directement à un serveur de localisation d'une information (jeton, session, ou « Groupe fermé de clients »), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client (C2) est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients et du serveur auprès duquel ce client est enregistré.
7.1.1.3.1. Accès initial pour la localisation du jeton
On présente, en relation avec la figure 4, un cas où le serveur de données de session (SDS2) auquel le client (C2) accède initialement est utilisé pour obtenir la localisation du jeton. A chaque fois que le client (C2) accède à un serveur de localisation d'une information (session, ou « Groupe fermé de clients »), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client (C2) est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients (SLC) et du serveur auprès duquel ce client est enregistré (SDS2).
Les différents serveurs de localisation sont donc utilisés tant par le serveur de données de session (SDS2) et le client (C2) pour retrouver la localisation d'informations que par les autres entités du réseau pour retrouver, par exemple, des informations sur le client (C2).
7.1.1.3.2. Accès initial pour l'obtention de l'identifiant de session
On présente, en relation avec la figure 5, un cas où le serveur de données de session (SDS2) auquel le client (C2) accède initialement est utilisé pour obtenir directement la session associée au jeton, la localisation du jeton étant gérée par ce serveur de données de session (SDS2).
Dans ce cas, à chaque fois que le client (C2) accède à un serveur de localisation d'une information (session, ou « Groupe fermé de clients »), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client (C2) est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients (SLC) et du serveur (SDS2) auprès duquel ce client est enregistré.
7.1.1.3.3. Accès initial pour l'obtention de la description de la session
On présente, en relation avec la figure 6, un cas où le serveur de données de session (SDS2) auquel le client (C2) accède initialement est utilisé pour obtenir directement la session associée au jeton et la localisation de celle-ci, la localisation du jeton étant gérée par ce serveur de données de session (SDS2).
A chaque fois que le client (C2) accède à un serveur de localisation de session (SLS) ou au serveur de données de session à même de délivrer l'information de session (SDS3), ce serveur doit vérifier que le client est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients et du serveur auprès duquel ce client est enregistré.
7.1.2. Scénarios simplifiés par utilisation d'URLs et d'adresses simplifiées pour les jetons, et des passeports numériques
On présente, dans les exemples qui suivent des modes de réalisation du procédé de l'invention basé sur l'utilisation d'URLs et d'adresses abrégées. Dans ces scénarios, on illustre différents modes de mise en œuvre de la simplification des échanges avec les options de simplification suivantes concernant l'adressage : - utilisation d'étiquettes de type « URL » pour la désignation des sessions,
« Groupe fermé de clients » et clients : leur localisation est donc implicite, utilisation d'étiquettes de type <Identifiant émetteur>+<jeton> pour la désignation des jetons : leur localisation est donc implicite, tout en limitant la taille des jetons à un minimum acceptable pour leur transport sûr et conservant la confidentialité de la session d'usage sur différents réseaux.
On présente ici un exemple de telles adresses élémentaires. Ainsi, le valeur "331038400567" en décimal est décomposée comme suit : "33" : désigne la France, " 10" : désigne un opérateur, - "384" : désigne un porteur d'association jetons/session,
"00567" : est le jeton.
La simple consultation d'une table en mémoire permet à chacune des parties de retrouver le porteur d'une association jetons/session, du moins dans les situations courantes. Dans les réseaux utilisés couramment, l'information <Identifiant émetteur>+<jeton> peut être par exemple portée par les champs suivants de la signalisation :
RTC : paramètre "données de contexte" au sein de la "demande de reroutage" de la Signalisation Usager-PCS (spécification France Télécom), dans un message "facilité" du protocole D de commande d'appel pour les accès RNIS, Web : cookie dans un message http de redirection; VoIP/SIP : header "history info" utilisation d'un système de type passeport numérique pour la mémorisation de l'information de validation de l'identification/authentification du client pour son parcours auprès des différents serveurs.
Le cas où les serveurs applicatifs clients n'ont qu'un accès indirect aux différents serveurs n'a alors plus de sens.
7.1.2.1. Exemple d'un système où les serveurs applicatifs clients ont un accès direct aux différents serveurs
On présente, en relation avec la figure 7, le cas d'un client qui n'est plus dans l'obligation de s'adresser à un serveur de localisation de jeton pour obtenir la localisation du jeton. En effet c'est le serveur de données de session (SDSl) porteur de l'association jeton/session, premier système touché, qui vérifie les droits du client C2 (par exemple par l'utilisation d'un passeport numérique) avant de pouvoir lui répondre. On simplifie donc les échanges par rapport aux cas présentés dans la figure 3 et la figure 4.
Ainsi, la simplification de l'adressage conduit à une suppression, au sein du réseau, des entités de localisation de jeton, de localisation de session et de localisation de groupe.
7.1.2.2. Exemple d'un système où les serveurs applicatifs clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre
On présente, en relation avec la figure 8, le cas où le serveur de données de session SDS2 auquel le client C2 accède initialement est utilisé pour obtenir l'identifiant de la session associée au jeton. Cet identifiant de session est ensuite, utilisé par la suite pour obtenir les données de la session d'usage. Ceci correspond à la simplification du cas présenté dans la figure 5, grâce à la réduction de la structure des adresses. Ainsi, la simplification de l'adressage conduit à une suppression, au sein du réseau, des entités de localisation de jeton, de localisation de session, de localisation de client et de localisation de groupe.
7.1.3. Cas des appels avec franchissement de passerelles entre opérateurs ou entre réseaux
Dans certains cas, il n'est pas aisé au client qui reçoit un appel, au sens large, c'est-à-dire une demande d'ouverture ou de continuation d'une session de communication, de déterminer d'emblée le porteur d'une association jeton/session, ne serait-ce que parce que l'appel a franchi une passerelle entre deux opérateurs, ou entre deux réseaux de nature différente.
En effet, dans ce cas, il est fort probable que l'information soit transformée en termes de support (champs non strictement équivalents dans les signalisations utilisées) et en termes de contenu (codages différents).
L'utilisation de systèmes permettant de retrouver l'information originelle s'impose alors, un tel système mettant en œuvre un serveur de localisation de jetons dotés de fonctionnalités particulières et opérant comme suit.
7.1.3.1. Fonctionnement d'un serveur de localisation des jetons
Deux types de serveur de localisation de jetons peuvent être imaginés.
Un premier type, que nous qualifierons d'actif, est capable de stocker en interne les informations décrivant le changement de forme d'un jeton lors de la traversée d'une passerelle, sans que le serveur de données de session en charge de la session en soit informé. Lorsqu'un tel serveur de localisation de jetons est interrogé, il est capable de restituer le jeton originel et le serveur de données de session porteur de l'association jeton/session. Un second type de serveur de localisation de jetons, que nous qualifierons de passif, utilise le serveur de données de session pour stocker les informations décrivant le changement de forme d'un jeton lors de la traversée d'une passerelle. Lorsqu'un tel serveur de localisation de jetons est interrogé, il est capable à partir du jeton courant de désigner le serveur de données de session porteur de l'association jeton/session. 7.1.3.1.1. Serveur de localisation des jetons actif
Le serveur de localisation des jetons actif, supposé ici unique, se comporte comme un serveur de données de session aux fonctionnalités réduites et a les fonctions suivantes : - Sur la demande d'une passerelle inter-réseau, recevant une demande d'appel sur un réseau et souhaitant la propager sur un autre réseau mais devant pour cela changer certaines informations constitutives de ce que l'on peut appeler un "contexte de jeton", par exemple :
Jeton, ou <adresse porteur de l'association J/S>+<jeton>, ou <type de jeton>+<jeton>, réseau sur lequel est reçu le jeton, ou <adresse de la dernière passerelle inter-réseau empruntée>, - identifiant d'appel ou de session de communication sur le réseau, adresses "demandeur" et "demandé" de l'appel, données d'historique d'appel (signalisation), stocke en interne le contexte de jeton entrant, - stocke également en interne le nouveau jeton utilisé par la passerelle, demandé auparavant par elle à un serveur de données de session (le SLJ pourrait le faire, dans une autre option de mise en œuvre), associe ce nouveau jeton au contexte de jeton et à l'ancien jeton, - retrouve une adresse d'un porteur d'une association jetons/session avec l'ancien jeton à partir du jeton courant et du contexte de jeton auparavant mémorisés, restitue à un client porteur du nouveau jeton cette adresse, avec les deux jetons, afin que ce client puisse retrouver la session associée. On présente, en relation avec la figure 9, un enchaînement d'action conduisant à l'échange de données de session entre des plateformes de services « PFS A » et « PFS B » communicant par le biais d'un intranet entre les plateformes de services et les serveurs de données de sessions « PFS-SDS ». Les plateformes de services « PFS A » et « PFS B » sont situées sur des réseaux de télécommunications différents et sont interconnectées par le biais d'une passerelle « P ». Ces actions se produisent selon la séquence suivante :
1) demande (901) de jeton [dj (I)] de la plateforme de services « PFS A » vers le serveur de données de session « SDSl », pour 1 jeton ; 2) réponse (902) à la demande de jeton [rJ(j')] fournissant un jeton j', ensuite association du jeton à la session S' ;
3) transmission (903) par la plateforme de services « PFS A » du jeton j' dans la signalisation, reçu par la passerelle inter-réseau « P » ;
4) la passerelle « P » informe (904) le serveur de localisation de jeton « SLJ » que le jeton j' est associé au contexte de jeton cj', par le message [iCJ(j', cj')] ;
5) la passerelle « P » demande (905) un jeton [dJ(l)] au serveur de données de session « SDS 2 », pour 1 jeton ;
6) le serveur de données de session « SDS 2 » répond (906) à la demande de jeton [rJ(j")], j" (ce jeton n'est pas ensuite associé à la session S', car il est utilisé comme alias) ;
7) la passerelle « P » informe (907) le serveur de localisation de jetons « SLJ » que le jeton j'"est un alias du jeton j', par le message iCJ(j" = j') (le serveur de localisation de jetons « SLJ » les associe en interne) ; 8) transmission (908) par la passerelle « P » du jeton j" dans la signalisation, reçu par la plateforme de services « PFS B » ; 9) la plateforme de services « PFS B » demande (909) au serveur de localisation de jeton « SLJ » la localisation du jeton j", par le biais du message dLJ(j") ; 10) le serveur de localisation de jeton « SLJ » répond (910) à la plateforme de services « PFS B », par le biais du message rLJ(j"= j', SDS 1), que le jeton j" est un alias du jeton j' et que le porteur de l'association de j' a une session est le serveur de données de session 1, qu'elle peut maintenant interroger.
Ainsi, si les passerelles inter-réseau ne peuvent transporter sans modification certaines informations du contexte de jeton, dont notamment le jeton, elles peuvent faire appel au serveur de localisation de jetons pour qu'il conserve la trace de cette modification et puisse restituer au client immédiatement en aval les informations de localisation correcte.
Cela demande cependant un enrichissement du protocole d'échanges entre le serveur de localisation de jeton et les passerelles et clients.
7.1.3.1.2. Serveur de localisation des jetons passif
Le serveur de localisation des jetons passif, supposé ici unique, a les fonctions suivantes :
Sur la demande d'une passerelle inter-réseau, recevant une demande d'appel sur un réseau et souhaitant la propager sur un autre réseau mais devant pour cela changer certaines informations constitutives de ce que l'on peut appeler un "contexte de jeton" (mais sans modification du jeton), par exemple :
Jeton, ou <adresse porteur de l'association J/S>+<jeton>, ou <type de jeton>+<jeton>, réseau sur lequel est reçu le jeton, ou <adresse de la dernière passerelle inter-réseau empruntée>, identifiant d'appel ou de session de communication sur le réseau, adresses "demandeur" et "demandé" de l'appel, - données d'historique d'appel (signalisation). stocke en interne le contexte de jeton entrant, retrouve le contexte de jeton à partir du jeton mémorisé, restitue à un client porteur du jeton le contexte de jeton contenant l'adresse du serveur de données de session porteur de l'association J/S, afin que ce client puisse retrouver la session associée.
On présente, en relation avec la figure 10, un enchaînement d'action conduisant à l'échange de données de session entre des plateformes de services « PFS A » et « PFS B ». Les plateformes de service « PFS A » et « PFS B »communiquent par le biais d'un intranet « PFS-SDS »avec les serveurs de données de sessions. Les plateformes de services « PFS A » et « PFS B » sont situées sur des réseaux de télécommunications différents et sont interconnectées par le biais d'une passerelle « P ». Ces actions se produisent selon la séquence suivante :
1) demande (1001) de jeton [dj(l)] de la plateforme de services « PFS A » vers le serveur de données de session « SDSl », pour 1 jeton ;
2) réponse (1002) à la demande de jeton [rJ(j')] fournissant un jeton j', suivi d'une association du jeton à la session S' ;
3) transmission (1003) par la plateforme de services « PFS A » du jeton j' dans la signalisation, reçu par la passerelle inter-réseau « P » ; 4) la passerelle « P » informe (1004) le serveur de localisation de jeton
« SLJ » que le jeton j' est associé au contexte de jeton cj', par le message [iCJ(j', cj')] ; 5) transmission (1005) par la passerelle « P » du jeton j' dans la signalisation, reçu par la plateforme de services « PFS B » ; 6) la plateforme de services « PFS B » demande (1006) au serveur de localisation de jeton « SLJ » la localisation du jeton j', par le message
[dLJ(j')] ; 7) le serveur de localisation de jeton « SLJ » répond (1007) à la plateforme de services « PFS B » que le porteur de l'association de j' a une session est le serveur de données de session « SDS1 », par le message [rLJ(j', SDSl)] et qu'elle peut maintenant l'interroger. Ainsi, si les passerelles inter-réseau ne peuvent transporter sans modification certaines informations du contexte de jeton, mais sans altération cependant du jeton, elles peuvent faire appel au SLJ pour qu'il conserve la trace de cette modification et puisse restituer au client immédiatement en aval les informations de localisation correcte.
Cela demande cependant qu'un enrichissement du protocole d'échanges entre le serveur de localisation de jetons et les passerelles, mais pas entre le serveur de localisation de jeton et les clients.
7.1.3.2. Scénarios simplifiés avec serveur de localisation de jetons
7.1.3.2.1. Exemple d'un système où les serveurs applicatifs clients ont un accès direct aux différents serveurs
Cet exemple est présenté en relation avec la figure 11. Le client C2 doit ici s'adresser au serveur de localisation de jetons SLJ pour obtenir la localisation du jeton, en lui indiquant par exemple le réseau d'où provient le jeton et les paramètres réseau reçus (adresses départ et arrivée, ou information d'historique par exemple).
De son côté, le serveur de localisation de jetons SLJ, qui est le premier système touché, doit vérifier les droits du client C2 avant de pouvoir lui répondre. Ici, les serveurs de localisation de session et les serveurs de localisation de groupes deviennent inutiles.
7.1.3.2.2. Exemples d'un système où les serveurs applicatifs clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre
Dans un tel mode de mise en œuvre, le client ne peut accéder aux différents serveurs détenteurs des informations qu'après un accès initial via un serveur de données de session particulier auprès duquel ce client est enregistré. Ce serveur de données de session peut être unique. 7.1.3.2.2.1. Accès initial pour la localisation du jeton En relation avec la figure 12, le serveur de données de session SDS2 auquel le client C2 accède initialement est utilisé pour obtenir la localisation du jeton. C'est ce serveur de données de session SDS2 qui doit s'adresser au SLJ pour obtenir la localisation du jeton, en lui indiquant par exemple le réseau sur lequel le client C2 a reçu et les paramètres réseau (adresses départ et arrivée, ou information d'historique par exemple) et que le client lui a retransmis.
Ici, les serveurs de localisation de client, de session et de groupe de clients deviennent inutiles.
7.1.3.2.2.2. Accès initial pour l'obtention de l'identifiant de session En relation avec la figure 13, le serveur de données de session SDS2 auquel le client C2 a accédé initialement est utilisé pour obtenir l'identifiant de la session associée au jeton, la localisation du jeton étant recherchée par le serveur de données de session SDS2 de rattachement qui doit s'adresser au serveur de localisation de jeton SLJ pour obtenir la localisation du jeton, en lui indiquant par exemple le réseau sur lequel le client a reçu et les paramètres réseau reçus (adresses départ et arrivée, ou information d'historique par exemple) et que le client lui a retransmis.
Ici, les serveurs de localisation de client, de session et de groupe de clients deviennent inutiles. 7.2. Architecture d'un dispositif d'obtention
On présente, en relation avec la figure 14, une architecture simplifiée d'un serveur de données de session selon l'invention. Il comprend une mémoire 141, et une unité de traitement 140 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 142. L'unité de traitement 140 reçoit en entrée, via un module d'interface d'entrée réseau 143, des réponses (adresses ou données) et des notifications 144.
Ces informations sont traitées par le microprocesseur, selon les instructions du programme 142, pour : émettre des messages de service 146a ; - émettre des requêtes 146b, par exemple des requêtes d'obtention de données de session ou d'adresses de localisation ;
Ces données sont transmises via un module d'interface de sortie réseau 145 à destination des dispositifs du réseau de communication qui en ont la charge.

Claims

REVENDICATIONS
1. Procédé de transmission de données, dans le cadre d'une communication établie entre au moins deux entités, caractérisé en ce qu'il comprend : une étape de réception par une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : un identifiant de typologie, désignant un type de message prédéfini ; une information représentative desdites données applicatives à obtenir ; une étape d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
2. Procédé de transmission selon la revendication 1, caractérisé en ce qu'il comprend, postérieurement à ladite étape d'identification, une étape d'émission d'un deuxième message à destination dudit serveur de localisation, ledit deuxième message comprenant : un deuxième identifiant de typologie, définissant un type dudit deuxième message parmi au moins deux types prédéfinis ; ladite information représentative des dites données applicatives à localiser.
3. Procédé de transmission selon la revendication 2, caractérisé en ce qu'il comprend, postérieurement à ladite étape d'émission dudit deuxième message, une deuxième étape de réception d'un message de localisation, en provenance dudit serveur de localisation, ledit message de localisation comprenant au moins une adresse applicative représentative d'une entité apte à délivrer lesdites données applicatives.
4. Procédé de transmission selon la revendication 3, caractérisé en ce que ladite adresse applicative comprend au moins une interface d'entrée/sortie qui est fonction d'au moins un traitement applicatif à réaliser.
5. Procédé de transmission selon l'une quelconque des revendications 3 et 4, caractérisé en ce qu'il comprend, postérieurement à ladite deuxième étape de réception de ladite adresse applicative : - une étape de vérification d'une autorisation de ladite entité émettrice à requérir lesdites données applicatives ; une étape d'interrogation de ladite entité apte à fournir lesdites données applicatives en fonction de ladite adresse applicative lorsque ladite autorisation est accordée.
6. Procédé de transmission selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : des messages de service ; des notifications ; - des commandes ; des requêtes.
7. Système de transmission de données incluant au moins deux entités, caractérisé en ce qu'il comprend : des moyens de réception inclus dans une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : un identifiant de typologie, désignant un type de message prédéfini ; une information représentative desdites données applicatives à obtenir ; des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
8. Dispositif de transmission incluant : des moyens de réception d'un message requérant des données applicatives, ledit message comprenant : un premier identifiant de typologie, désignant un type de message prédéfini ; - une information représentative desdites données applicatives à obtenir ; des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
9. Produit 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 de code de programme pour l'exécution du procédé de transmission selon l'une au moins des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2008/051358 2007-07-19 2008-07-17 Procede d'obtention de donnees applicatives Ceased WO2009013441A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0756607A FR2919141A1 (fr) 2007-07-19 2007-07-19 Procede d'obtention de donnees applicatives
FR0756607 2007-07-19

Publications (1)

Publication Number Publication Date
WO2009013441A1 true WO2009013441A1 (fr) 2009-01-29

Family

ID=39322500

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/051358 Ceased WO2009013441A1 (fr) 2007-07-19 2008-07-17 Procede d'obtention de donnees applicatives

Country Status (2)

Country Link
FR (1) FR2919141A1 (fr)
WO (1) WO2009013441A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001042966A2 (fr) * 1999-12-13 2001-06-14 Novient, Inc. Synchronisation d'attributs et d'applications dans un environnement reseau reparti
US20030031164A1 (en) * 2001-03-05 2003-02-13 Nabkel Jafar S. Method and system communication system message processing based on classification criteria
WO2005059746A1 (fr) * 2003-12-17 2005-06-30 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de traitement de messages optimise de façon dynamique
US20050289096A1 (en) * 2004-06-23 2005-12-29 Nokia Corporation Method, system and computer program to enable SIP event-based discovery of services and content within a community built on context information
US20060047814A1 (en) * 2004-08-27 2006-03-02 Cisco Technology, Inc. System and method for managing end user approval for charging in a network environment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001042966A2 (fr) * 1999-12-13 2001-06-14 Novient, Inc. Synchronisation d'attributs et d'applications dans un environnement reseau reparti
US20030031164A1 (en) * 2001-03-05 2003-02-13 Nabkel Jafar S. Method and system communication system message processing based on classification criteria
WO2005059746A1 (fr) * 2003-12-17 2005-06-30 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de traitement de messages optimise de façon dynamique
US20050289096A1 (en) * 2004-06-23 2005-12-29 Nokia Corporation Method, system and computer program to enable SIP event-based discovery of services and content within a community built on context information
US20060047814A1 (en) * 2004-08-27 2006-03-02 Cisco Technology, Inc. System and method for managing end user approval for charging in a network environment

Also Published As

Publication number Publication date
FR2919141A1 (fr) 2009-01-23

Similar Documents

Publication Publication Date Title
CN105340251B (zh) 用于为呼叫中心加密并记录媒体的系统和方法
EP1376410B1 (fr) Procédé de gestion d&#39;informations de contexte par serveur intermédiaire
US20130142318A1 (en) Peer-to-peer telephony recording
EP2795878B1 (fr) Procédé de partage d&#39;un contenu multimédia entre utilisateurs
US20060095556A1 (en) Method and apparatus for automating collaboration over communications devices
EP3162032A1 (fr) Orchestration de ressources physiques et virtuelles pour la livraison de contenus numériques
EP1204044A1 (fr) Procédé et système d&#39;optimisation de consultations d&#39;ensembles de données par une pluralité de clients
FR2855691A1 (fr) Securisation de la distribution de documents numeriques dans un reseau pair a pair
EP2797010A2 (fr) Système et procédé de stockage et de récupération de support d&#39;interaction distribué
FR2802373A1 (fr) Systeme et methode pour personnaliser la qualite des services en fonction des clients dans un environnement informatique collaboratif
FR2931330A1 (fr) Procede et systeme d&#39;enregistrement automatique d&#39;une session de communication
EP2795870B1 (fr) Procede d&#39;acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
WO2004095816A2 (fr) Procédé d’établissement communications entre terminaux choisis d’utilisateurs, par l’intermediaire d’équipements de communication dédiés
WO2009013441A1 (fr) Procede d&#39;obtention de donnees applicatives
EP3123700B1 (fr) Procede de mise en cache d&#39;un contenu dans un reseau de distribution de contenus
FR3129504A1 (fr) Procédés, terminal et serveur de gestion de données personnelles
EP2529330B1 (fr) Procédé de fourniture d&#39;un code dynamique par l&#39;intermédiaire d&#39;un téléphone
EP2171966B1 (fr) Gestion de sessions multi-flux entre un terminal et un serveur
WO2009013440A1 (fr) Procede d&#39;echange de messages entre serveur de donnees de session et des services clients
EP1193946B1 (fr) Procéde et réseau de communication
FR3121808A1 (fr) Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
WO2025017639A1 (fr) Système et procédé de gestion de service &#34;cliquer pour appeler&#34; instantané
EP1005206A1 (fr) Système multimédia de transmission de données
EP2664127A1 (fr) Construction d&#39;une requete de retention de donnees ou d&#39;interception legale a partir d&#39;une autre requete
EP2115999A1 (fr) Reseau de communication comprenant des moyens de gestion de conflits lors de l&#39;execution de plusieurs services de communication

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

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

Country of ref document: EP

Kind code of ref document: A1