Method for processing a telephony request

Abstract

The invention relates to a method for processing a telephony request (RQ), referred to as request to be processed, belonging to a telephony session, referred to as current session, by way of a processing server (SBE) belonging to a group (GP) of servers, characterized in that the request (RQ) to be processed includes a value (V), referred to as key value, and characterized in that the method comprises the steps of receiving the request (RQ) to be processed; of reading, from a database (SDB), an item of information (INF) relating to the current session accessible by virtue of the key value (V); and of processing the request (RQ) to be processed using the read item of information (INF).

Description

Method for processing a telephony request

[0001] The technical field is that of telephony.

[0002] More specifically, the invention relates to a method for processing a telephony request. It also relates to a method for managing the allocation to a processing server of telephony requests belonging to a telephony session as well as to associated methods for managing a telephony session by a telephony system. The invention also relates to a management entity, to a processing server, and to a telephony system comprising a management entity and a group of processing servers.

[0003] The implementation of telephone services aims to open telephone communications, also called connections, between two or more telephone terminals. A calling terminal requests the opening of a telephone connection with another terminal, the called terminal, by sending an opening request to a processing server. The latter processes the request and establishes a point-to-point connection between the calling terminal and the called terminal, collaborating with other servers to establish the connection. Once the connection is established, a multimedia communication between at least the calling terminal and the called terminal will allow the telephone communication to take place.

[0004] Telephone communication therefore requires, on the one hand, exchanges following a given protocol to establish the connection, and on the other hand, an exchange of multimedia data according to another protocol to carry the voice and possibly the image of the interlocutors. The protocol(s) allowing the connection to be established are traditionally called signaling protocols.

[0005] These concepts first appeared in traditional telephony, for example that using the public switched telephone network (PSTN, called Plain Old Telephone System in English, or POTS) or, more recently, with the Integrated Services Digital Network (ISDN, called ISDN). Telephone terminals were then simply called telephones and the servers that establish telephone connections were switches, and in particular, automatic branch exchanges from the development of digital telephony. Access from terminals to servers was traditionally via a wired network and has used electromagnetic waves for wireless telephony since the end of the twentieth century.

[0006] These concepts are still found in modern telephony, which uses the IP protocol (acronym for Internet Protocol) to transmit both the data needed to establish telephone connections during the signaling stages and, once the connection is established, to transfer multimedia data (sound and image) between terminals. Establishing the telephone connection will often use the SIP protocol (acronym for Session Initiation Protocol) as the signaling protocol, while transporting multimedia data between the two terminals, once the connection is established, often uses the RTP protocol (acronym for Real-time Transport Protocol). The H.323 protocol is also used. H.323 can also be described as a combination of several different protocols that can be grouped into three categories: signaling, negotiation of codecs (short for codecs) that will encode and decode the analog voice signal emitted by users into digital data for transport, and finally the transport of multimedia data, mainly the voice signal emitted by users.

[0007] We then speak of IP telephony, which includes in particular voice telephone communications or VoIP (acronym for Voice over IP) but also includes the transfer of multimedia data as well as signaling. It should be noted that the signaling protocol(s) allow communications to be established but also provide more sophisticated services than simply establishing point-to-point connections, such as establishing three-way calls, conferences, call waiting, call transfer, caller ID, call blocking or any other telephony service. In IP telephony, telephone terminals are traditionally called IP telephones.

[0008] The invention applies to IP telephony but extends to other telephony systems. State of the art

[0009] Telephony, whether traditional telephony or IP telephony, requires the implementation of a stateful protocol, meaning that the establishment of telephone communications is done by taking into account the state of the telephone terminals, which will evolve throughout the telephone communication. Obviously, a terminal that has already established a telephone communication, which is therefore busy, will not accept an additional communication request. When the initial communication is cut off, the terminal goes to the free state, and can therefore respond positively to a new telephone communication request and will then go back to the busy state.This concept of a stateful protocol is opposed to that of a stateless communication protocol (translation of the English stateless protocol) in which the participants in the protocol only exchange questions and answers without having any change of state. A particularity of IP telephony is that it is a stateful protocol, like any telephone protocol, implemented using a stateless protocol, namely the IP protocol.

[0010] Implementing an IP telephony system also means that a large number of telephone terminals will require a smaller number of servers. These servers can be divided into two main categories: Servers for processing requests relating to signaling, which enable telephone communications to be established and provide telephony services, such as call waiting, three-way communications, or others. Multimedia servers that ensure the transport of multimedia data between telephone sets.

[0011] Similarly, request processing servers include application servers (AS), which provide the various types of telephone services provided in IP telephony, and session border controllers (SBC). SBC servers are located at the edge of IP telephony networks and are responsible for communications with elements outside these networks, or from one IP telephony network to another. In particular, SBC servers are responsible for communications with terminals, i.e., IP telephones, which are considered to be outside the IP telephony network itself.SBC servers can be seen as comprising a component that handles the signaling aspects, called a session border element, often referred to as an SBE, and a component that handles the media aspects, namely a media gateway, often referred to as an MGW.

[0012] In the field of IP telephony, the distribution of requests from telephone terminals to IP telephony request processing servers traditionally takes place as follows: each terminal is assigned a dedicated server that will manage all communications for this terminal. This server is most often an SBC server. In the event of a failure of the SBC server, it has a backup server that will take over the current telephone connections managed by the server before its failure. In this way, the management of the stateful telephony protocol and the telephony sessions in which the IP telephones participate is ensured by the processing server that is associated with a given fleet of IP telephones.

[0013] During a telephone session, the processing server always remains the same and will process all requests belonging to the current session.

[0014] This situation has drawbacks.

[0015] First, it requires reserving a large amount of hardware and computing resources. If a server of a given size is sized to manage telephone communications for a terminal fleet of a certain size, it is actually necessary to double the number of servers to provide telephone service. In general, an SBC server is sized to handle a fleet of around 100,000 terminals. When an IP telephony network handles a little more than 100,000 IP phones, at some point it will be necessary to add a new SBC server (and its backup server), which will double the number of SBC servers deployed. This solution does not allow the number of servers to be modulated according to needs, even though these vary over time; for example, telephone communication needs are much higher in a professional context during the day than at night, but the number of SBC servers deployed for a given IP telephone fleet will not change.

[0016] Furthermore, this situation makes it difficult to easily add new terminals. Each time, a server and its duplicate must be added to accommodate new servers. The IP phone allocation plan for SBC servers must also be redefined to prevent a new SBC server from supporting only a few terminals at launch, which would not relieve the load on the SBC servers already deployed.

[0017] Second, this situation requires making assumptions about the rate of use that IP phones will make of the telephone service in order to determine how many servers should be provided for a given fleet. These assumptions may be wrong and adapting the number of servers will then be quite difficult because it will require assigning new servers to terminals when their number is adjusted downwards or upwards.

[0018] Finally, SBC servers in this situation are stateful servers, which must take into account the state of the phone sessions they manage. This adds complexity to the development of these servers, making them more susceptible to software failure.

[0019] One possible solution that has been used is to assign a group of SBC servers to a given IP phone fleet and use load balancing tools to better distribute the load among the SBC servers deployed for a given fleet. However, in this solution, a single server will always be responsible for handling a given IP telephony session from end to end. If a server fails, the ongoing communications handled by that server are then interrupted. And the servers, which handle all the requests for a given session, are always stateful servers, therefore complicated to develop from a software point of view.

[0020] The invention improves the situation.

[0021] According to a first functional aspect, the invention relates to a method for processing a telephony request, called a request to be processed, belonging to a telephony session, called a current session, by a processing server belonging to a group of servers, characterized in that the request to be processed includes a value, called a key value, and in that the method comprises the following steps: Reception of the request to be processed; Reading in a database information relating to the current session accessible using the key value; Processing of the request to be processed using the information read.

[0022] Thanks to the invention, the processing of a request in a current session is no longer carried out by a single server throughout the session but by a server that belongs to a group of servers and that can change from one request to another throughout the session. Thanks to a key value, it is possible for the server in charge of processing the request to find the necessary information in a database, which will often be called a session database. This key value is not necessarily unique throughout a current session. The processing is therefore no longer carried out by a single server that must be reserved in advance but by a server chosen on demand, according to load optimization considerations for example. Indeed, the processing server chosen at a given moment of the current session will have access to the key value and therefore to the information in the database that contains the history of the current session, necessary for the processing.

[0023] In embodiments, a management entity assigns the request to the processing server. The processing server is often referred to as the assigned server. Once the request has been assigned to a processing server by the management entity responsible for this aspect of the invention, the request is transmitted by the management entity and received by the processing server. The latter will then read from a database called the session database one or more pieces of information relating to the current session. The session database can be accessed by the servers belonging to the server group. In this way, the processing server can retrieve all the information useful for processing the request, which takes into account the processing of previous requests that took place in the same session.This functionality allows the processing of a telephony protocol, which is by nature a stateful protocol, to be carried out using a stateless method in which a telephony request is allocated, including in certain modes randomly, to a server among a group of servers. The processing of the request is then carried out according to the classic functionalities of a telephony processing server, once the information relating to the session has been obtained by the server.

[0024] In traditional telephony, processing servers are assigned to phones, for example IP phones, and they store useful session information locally. Thanks to the invention, servers no longer have to be statically assigned to phones; requests are assigned to them on the fly and they retrieve the necessary session information from a database that can be accessed by the processing servers in the group so that a server to which the request is assigned can retrieve the necessary information.

[0025] The advantage of the invention is then the saving of energy, hardware, computing and memory resources since it is no longer necessary to reserve a large number of servers for a given fleet of telephones.

[0026] Another advantage of the invention is the robustness of the solution. If a server fails in the processing server group, the other servers in the group will take over in processing the requests to be processed. This is also true if a second server fails, whereas in conventional telephony operation, it is enough for one server to fail, then its backup server, for an entire fleet of telephones to be deprived of telephony service.

[0027] Furthermore, the failure of a processing server will not involve the interruption of the telephone sessions managed by this server since, in the same telephone session, the different requests are processed, one by one, by different servers.

[0028] The key value is taken from a field in the query. Several implementations are possible. In one mode, a given field always takes the same value for all queries in the same session. The key value will then be the value of this field, which will allow us to retrieve information associated with all past queries in the session and therefore will allow us to know what processing to do for the current query in the session. In another mode, the key value is taken from a given field and, for the same field, at least one other past query in the session takes the same value. However, other past queries in the same session will not necessarily have the same value for the same field. For these other past queries, another value, potentially from another field, will serve as the key value. Several distinct values ​​taken from several fields can serve as the key value.It is then possible, step by step, to find in the database all the useful information associated with the various past requests.

[0029] According to a particular embodiment of the invention, the key value is equal to a value included in a previous request to be processed belonging to the current session.

[0030] Thanks to this first embodiment of the invention, a method for retrieving information relating to the session is provided. To do this, a key value is identified which will be found from the request to be processed in a previous request of the current session. Gradually, it is possible to retrieve the information necessary for processing a request to be processed. These values ​​are found, for example, in the header fields of requests according to the SIP protocol. The programming of the session database makes it possible to extract the information relevant to the processing of a given request from the key value by going back step by step in the previous requests of the current session. The links between different key values ​​entered in the session database can make it possible to carry out this information upload step by step.

[0031] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiment, the request to be processed is the initial request of the telephony session and reading in the session database does not provide any information.

[0032] Similar to the operation of the method for managing the allocation of a request, the retrieval of information from a key value will not provide any information in the case of processing the initial request of a telephony session. The session database can still, in this embodiment, be queried, but will not provide any information relating to the current session since the request processed is the initial request of the latter.

[0033] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiment, the number of processing servers belonging to the group of servers varies over time.

[0034] Thanks to this embodiment of the invention, the group of processing servers that will carry out the processing of telephony requests is not fixed, depending on the number of telephones processed by the processing servers, but will grow or decrease over time. In this way, adapting the number of processing servers to demand is much more flexible. For example, the number of active servers will decrease at night when telephony needs decrease. Thus, the energy and material resources mobilized by the processing servers are saved.

[0035] According to one embodiment, the request to be processed comes from a telephone and the processing server is selected by a management entity independently of said telephone.

[0036] With this mode, processing servers are separated from a fleet of phones to which they would be assigned once and for all. For a given phone, the servers that will process its requests will change over time, and in particular during phone sessions.

[0037] According to one embodiment, the processing server is selected by a management entity so as to distribute the processing load between the different servers of the group and the management entity is a load balancer.

[0038] With this mode, the processing load is distributed efficiently by the management entity which assigns the requests to the processing servers in the group.

[0039] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the method further comprises a step of recording in the database information resulting from the processing by the assigned server of the request to be processed, said information being recorded in association with the key value.

[0040] Once the processing is completed, it is useful, in general, for the processing server that has just processed a telephony request to enter information into the session database that is useful for subsequent processing of requests relating to the same session. In this way, the subsequent processing necessary to complete the session can be carried out by other processing servers than the one that has just processed the request. The information useful for subsequent processing will then be accessible using the key value that will be found, for example, by the next request in the same session.

[0041] This operation is not, however, a necessary operation in all cases and may be omitted depending on the nature of the telephony request. For example, once a telephone connection is established, there is a multimedia data transfer channel between two telephones (at least), i.e., a data connection managed by multimedia servers. Let us suppose that a telephony request consists of changing a parameter of this connection, for example a parameter relating to sampling, or data latency or any other aspect managed by the multimedia servers. The processing of the request will then consist of sending the multimedia servers an instruction to change the parameter.But if it is not useful to keep this information for later processing, because it is only the multimedia servers that need this information for example, the fact of not recording information relating to the processing in the session database will allow saving memory and time resources that would have been wasted by making this recording.

[0042] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the reading step is omitted depending on the nature of the request to be processed.

[0043] With this embodiment, the processing of the telephony request is accelerated since the reading of information in the session database is omitted. This step can be omitted, for example, when the nature of the request allows it to be deduced that this request creates the session and there has been no previous request that could have left information necessary for the processing of the current request.

[0044] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the session base is a cluster of high-availability databases.

[0045] Thanks to this embodiment, the efficiency of the invention is improved and in particular the availability of the service. We have seen that the invention makes it possible to withstand server failures since the telephones are no longer allocated to a given server but address their telephony requests to a group of servers, each of which can potentially handle processing. However, the invention uses a database accessible to all the servers in the group which can become a single point of failure. If the session database no longer works, the processing servers can no longer retrieve information relating to the sessions and can no longer process the requests.To significantly reduce the likelihood of this risk occurring, the session database functionality is implemented in this mode not by a single database, but by a high-availability database cluster. This implementation therefore significantly reduces the likelihood of unavailability of the telephony service caused by unavailability of the session database.

[0046] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the request to be processed comprises a field whose value taken is identical for all the requests to be processed belonging to the same telephony session.

[0047] According to another embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the key value is identical for all requests to be processed belonging to the same telephony session.

[0048] With these embodiments, information present in the requests to be processed makes it possible to find all the requests belonging to the same telephony session. The different requests of the same session are always in this mode attributed to different servers in the group. But the presence of such information, which constitutes a session identifier, makes it easier to process the requests by the different servers.

[0049] According to another functional aspect, the invention relates to a method of management by a management entity of the allocation to a processing server, belonging to a group of servers, of telephony requests, called requests to be processed, belonging to the same telephony session, called current session, characterized in that, during the current session, a reception of a request to be processed triggers a selection of a processing server in the group of servers, and in that the request to be processed is transmitted to the selected server, called allocated server, for processing.

[0050] Thanks to the invention, telephone terminals, for example those that implement IP telephony, are no longer assigned to a predefined telephony server. To this end, telephony requests issued by the terminals are allocated during a session to processing servers on a case-by-case basis, request by request, after being received by a management entity. In this way, it is no longer necessary to reserve resources in advance by assigning a server and its backup server to a predetermined number of telephones. In addition, a processing server is assigned to one request of the session, and not to process an entire session from start to finish. Thanks to the invention, a group of request processing servers will process requests on demand. In the event of a processing server in the group failing, the other servers in the group can replace it.It is therefore no longer necessary to provide a backup server for all the telephony processing servers assigned to a pre-defined terminal pool. And in the event of a failure of a server in the group, this does not prevent the ongoing sessions for which this server had intervened from continuing despite everything. In other words, whereas, in the current situation, a processing server failure will compromise the establishment and continuation of telephone communications managed by this server, this is not the case thanks to the invention since the servers only manage individual session requests and not an end-to-end session.

[0051] According to a particular embodiment of this aspect of the invention, the request to be processed includes a field which takes a value, called key value, which is equal to the value taken by the same field of a previous request to be processed belonging to the current session, and the request to be processed transmitted to the assigned server includes the key value.

[0052] This embodiment facilitates processing throughout a telephony session by different servers. Processing servers will be able to retrieve information about previous requests in the session using a key value that is identical in at least one previous request. By retrieving information step by step, a processing server will be able to have information about the processing performed by other servers. Passing the key value in the request to the assigned server helps achieve this goal.

[0053] Other embodiments are possible. For example, the session database can record all the telephony requests processed by the telephony system, and return this set of requests at the request of a processing server. The processing server then analyzes this set to determine the information useful for processing the request assigned to the server. This embodiment involves processing a larger amount of data but has the advantage of simplifying the operation of the session database, which only has to record all the processed requests and provide them on request.

[0054] According to another particular embodiment of this aspect of the invention, which may be implemented alternatively or cumulatively with the previous embodiment, the server allocated to process the request to be processed is different from the processing server which was allocated by the management entity to process the previous request to be processed belonging to the same telephony session.

[0055] Thanks to this mode, the different requests of the same telephony session are processed by different servers in the server group as a priority. In this way, unlike the situation in the prior art, a processing server is not responsible for an end-to-end session, which means that when a server fails, all the sessions processed by this server are impacted. Here, thanks to the invention, when a server fails, the telephone communications that this server helped to set up are not impacted.

[0056] Furthermore, in the invention, a processing server is a stateless server, which does not have to memorize the state of a telephony session. Indeed, the management entity assigns the requests one by one to the processing servers, without assigning all the requests of the same session to a single server. The assigned server therefore only processes one request, individually and independently of the other requests of the telephony session. Such a processing server is therefore indeed stateless, without the need to memorize the state of the session to which the processed request belongs. Such a server is easier to develop than a processing server which must memorize the state of the sessions it processes as in the prior art. Such a simpler server is more robust, which improves the quality of the telephony service in general.

[0057] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the request to be processed is the initial request of the telephony session and there is no previous request to be processed in the current session.

[0058] In the general case, a different server will be assigned to the request to be processed than the one assigned to the previous request in the telephony session. However, this cannot be the case for the initial request of the telephony session. Thanks to this aspect of the invention, this particular case is handled.

[0059] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the number of processing servers belonging to the group of servers varies over time.

[0060] With this mode, the group of processing servers that will handle telephony requests is not fixed, depending on the number of telephones handled by the processing servers, but will grow or shrink over time. In this way, adapting the number of processing servers to demand is much more flexible. For example, the number of active servers will decrease at night when telephony needs decrease. This saves energy and material resources used by the processing servers.

[0061] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the request to be processed comes from a telephone and the assigned server is selected by the management entity independently of said telephone.

[0062] Telephony requests are generally issued by telephones. In this embodiment, it is specified that the processing servers are not allocated using the identity of the issuing telephone, because this would amount to assigning a processing server to a given pool of telephones. Here, a telephone that issues a telephony request will have it received first by the management entity which will then assign it to a processing server. A subsequent request from the same telephone can then be assigned to another processing server. In this way, the invention makes it possible to avoid assigning a processing server to a pool of telephones in advance.

[0063] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the requests to be processed include fields which take a set of values ​​and the assigned server is selected by the management entity independently of said values.

[0064] Thanks to this particular embodiment of the invention, the management entity assigns the processing of the request to a server without taking into account the values ​​of the fields included in the request. In this way, the allocation is accelerated because the management entity does not have to consult the fields of the request before assigning it. In addition, assigning the processing server independently of the values ​​taken by the fields of the request guarantees that, in the general case, the assigned server will be quite different. In other words, several different processing servers will be assigned to the different requests throughout the telephony session.

[0065] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding embodiments, the management entity accesses a database, called the session database, and the assigned server is chosen by the management entity after reading by the management entity of information recorded in the session database accessible using the key value.

[0066] Here, unlike the previous mode, the management entity uses field values ​​present in the request to assign the request to be processed to a processing server, and in particular a key value, which is found from one request to another. This mode takes more time at the time of allocation because the management entity must retrieve the values ​​in question and consult information relating to the session saved in a database called a session database. But this mode can be more efficient in the end, for example by assigning the requests of a given session, or part of a given session, to a single processing server. In this case, we still gain in efficiency compared to the mode where the servers are assigned in advance to terminals, because there is no need to reserve a given number of servers based on the number of terminals but simply a number of servers adapted to the number of sessions to be processed that is expected.

[0067] In addition, mixed implementations can be deployed in which some requests will be assigned without taking into account the values ​​of the fields, and for other categories of requests, it will be necessary to assign successive requests of the same category of the same session to the same server and in this case consult information present in a session database separate from the management entity. Such information will be accessible thanks to the key value.

[0068] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the allocated server is selected by the management entity so as to distribute the processing load between the different servers of the group and the management entity is a load balancer.

[0069] The management entity can be a load balancer that will ensure that telephony requests are well distributed among the different processing servers in the group. Thanks to this implementation, the computing resources used by the processing servers are optimized since there is no imbalance between underutilized servers and overutilized servers. This mode also has the advantage of improving the reliability of the processing servers by avoiding possible overloads by distributing the load as best as possible.

[0070] According to another particular mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous modes, the allocated server is chosen by the management entity randomly.

[0071] This implementation provides a simple way to achieve load balancing. This involves assigning a processing server to a request by random selection. This technique is easy to implement and achieves an appropriate distribution of requests between servers.

[0072] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the allocated server is chosen using a so-called round-robin algorithm.

[0073] A round-robin algorithm is a classic load balancing algorithm. With this implementation, a known load balancing algorithm is used in the telephony field. One advantage is that it can benefit from technologies known elsewhere in this field, and therefore reuse existing software. The round-robin algorithm allows for efficient distribution and will therefore also improve resource utilization by the processing servers. Such distribution is done without taking into account the elements of the request relating to the current telephony session, such as the values ​​taken by the fields of the request for example. Several requests from the same session will therefore be allocated to different processing servers.

[0074] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the management entity uses a domain name server which will allocate the request to be processed by replacing a domain name used by the request with an IP address which will be that of the allocated server.

[0075] To achieve load balancing, one possible way is to use a domain name server that will implement the DNS protocol (acronym for Domain Name Service). In this embodiment, a telephone, which is in this embodiment an IP telephone, will address a query to a domain name using the IP protocol, and it is the domain name server that directs the query to a possible IP address for this domain name. The IP address will then be that of the processing server that will process the IP telephony query. This embodiment therefore makes it possible to obtain an alternative embodiment of the invention. The various load balancing techniques can be integrated into the domain name server in order to optimize the distribution of query processing between servers.

[0076] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the management entity uses a virtual IP address mechanism.

[0077] With this embodiment, an alternative is proposed for the allocation of requests. The virtual IP address mechanism is lighter than the deployment of a domain name server and also makes it possible to direct a request to a server among a group of servers, a request which initially uses a virtual IP address. Here again, such a distribution is done without taking into account the elements of the request relating to the current IP telephony session, such as the values ​​taken by the fields of the request for example. Several requests from the same session will therefore be allocated to different processing servers.

[0078] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the requests to be processed include a field whose value taken is identical for all the requests to be processed belonging to the same telephony session.

[0079] According to another embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the key value is identical for all requests to be processed belonging to the same telephony session.

[0080] With these embodiments, information present in the requests to be processed makes it possible to find all the requests belonging to the same telephony session. This information is not used for allocation, and the different requests of the same session are always in this mode allocated to different servers in the group. But the presence of such information, which constitutes a session identifier, makes it easier to subsequently process the requests by the different servers.

[0081] According to another functional aspect, the invention relates to a method for managing a telephony session, called the current session, by a telephony system, said system comprising a management entity responsible for assigning a telephony request, a group of processing servers, and a database, the current session comprising telephony requests, called requests to be processed, characterized in that, during the current session, a reception of a request to be processed by the management entity triggers a selection of a processing server in the group of servers, and in that the request to be processed is transmitted by the management entity to the selected server, called the assigned server, for processing, and in that the request to be processed includes a value, called the key value, and in that the assigned server processes a request to be processed by carrying out the following steps:Receiving the request to be processed transmitted by the management entity;Reading information from the database relating to the current session accessible using the key value; Processing the request to be processed using the information read.;

[0082] Thanks to the invention, the complete processing of a telephony session is carried out by a telephony system according to the invention. A request belonging to a telephony session is assigned by a management entity included in the system to a server belonging to a group of servers included in the system. These servers are assigned by the management entity to balance the load, without taking into account a priori the state of the current telephony session. In addition, the processing servers are also stateless servers. A given server will not process a telephony session in its entirety but one or more requests of the session, according to the assignment made by the management entity, for example according to the load balancing needs. The information relating to the session, necessary for processing the request, is then retrieved by the processing server from the session database.

[0083] Thanks to the invention, flexible management of a telephone session is made possible, without prior allocation of processing servers to a given telephone pool or even to a given session, since the different requests of the same session will generally be allocated to different servers.

[0084] According to a particular embodiment of the invention, the key value is equal to a value included in a previous request to be processed belonging to the current session.

[0085] This implementation makes it easier to retrieve session-related information from the session database. A query has a key value that allows you to retrieve, step by step, information from the session database relating to the processing carried out on previous queries in the same session.

[0086] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiment, the method further comprises a step of recording by the assigned server in the database of information resulting from the processing by the assigned server of the request to be processed, said information being recorded in association with the key value.

[0087] Once the processing is completed, it is useful, in general, for the processing server that has just processed a telephony request to enter information into the session database that is useful for subsequent processing of requests relating to the same session. In this way, the subsequent processing necessary to complete the session can be carried out by other processing servers than the one that has just processed the request. The information useful for subsequent processing will then be accessible using the key value that will be found, for example, by the next request in the same session.

[0088] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the requests to be processed include a field whose value taken is identical for all the requests to be processed belonging to the current session.

[0089] According to another embodiment of the invention, which may be implemented alternatively or cumulatively with the previous embodiments, the key value is identical for all requests to be processed belonging to the same telephony session.

[0090] With these embodiments, a value is found identically in all requests of the session that is managed by the telephony system. Such a value serves as a session identifier and simplifies the processing carried out by the session database to provide information useful for processing session requests.

[0091] According to a material aspect, the invention relates to a management entity capable of carrying out a method for managing the allocation to a processing server, belonging to a group of servers, of telephony requests, called requests to be processed, belonging to the same telephony session, called session in progress, characterized in that the management entity comprises: A module for receiving a request to be processed; A module for selecting a processing server in the group of servers; A module for transmitting a request to be processed;

[0092] and in that, during the current session, a reception by the reception module of a request to be processed triggers a selection by the selection module of a processing server in the group of servers, and in that the request to be processed is transmitted by the transmission module to the selected server, called the assigned server, for processing.

[0093] According to a material aspect, the invention relates to a server for processing a telephony request, called a request to be processed, belonging to a telephony session, called a current session, said processing server belonging to a group of servers, characterized in that the request to be processed includes a value, called a key value, and in that the server comprises the following modules: A module for receiving the request to be processed; A module for reading in a database, called a session database, information relating to the current session accessible using the key value; A module for processing the request to be processed using the information read.

[0094] According to one embodiment, the request to be processed is transmitted to the processing server by a management entity responsible for allocating the requests to be processed for the current session.

[0095] According to a particular embodiment of the invention, the key value is equal to a value included in a previous request to be processed belonging to the current session.

[0096] According to another particular embodiment, the invention relates to a processing server further comprising a module for recording in the session database information relating to the processing by the processing server of the request to be processed, said information being accessible using the key value.

[0097] According to another material aspect, the invention relates to a telephony system comprising a management entity according to the invention, a group of processing servers according to the invention and a database.

[0098] According to another material aspect, the invention relates to a computer program capable of being implemented by a management entity, the program comprising code instructions which, when executed by a processor, carry out the steps of the management method defined above.

[0099] According to another material aspect, the invention relates to a computer program capable of being implemented by a server for processing a telephony request, the program comprising code instructions which, when executed by a processor, carry out the steps of the processing method defined above.

[0100] Finally, according to another material aspect, the invention relates to data media on which are recorded computer programs comprising sequences of instructions for implementing the management and processing methods defined above.

[0101] The data carriers may be any entity or device capable of storing the programs. For example, the carriers may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means such as a hard disk. On the other hand, the carriers may be transmissible media such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The programs according to the invention may in particular be downloaded from a network such as the Internet. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. Brief description of the figures

[0102] The invention will be better understood on reading the following description, given by way of example, and made with reference to the appended drawings in which:

[0103] represents a telephony system comprising a management entity according to the invention, a group of processing servers according to the invention and a database.

[0104] illustrates an example of message exchanges carried out during a telephone session established using the methods according to the invention.

[0105] represents another example of architecture of a telephony system according to the invention. Detailed description

[0106] In the exemplary embodiments given in Figures 1, 2 and 3, the invention is implemented in the context of IP telephony. The invention can be implemented in the context of other telephony protocols in which several processing servers are likely to be involved.

[0107] La represents an IP telephony system SYS comprising a management entity 100 capable of carrying out a method for managing the allocation of an IP telephony request to a processing server; a GP group of processing servers SBE, SBE', SBE''; a database SDB, herein referred to as a session database; and other servers AS, AS', AS'', MGW, MGW' and MGW''. La represents an exemplary embodiment of the invention among other possible embodiments.

[0108] It also represents IP telephones, including one called TEL1, and an NWK communications network.

[0109] The NWK network is an IP (Internet Protocol) network, public or private, that connects the SYS IP telephony system and other similar systems, as well as IP phones, including the TEL1 phone, managed by the SYS system. It can be a wired or wireless network depending on the physical technology used, or a mixture of wired and wireless networks. The NWK network can be a local area network, a metropolitan area network, an international area network, or a combination of local area networks linked together by a transport network between several sites. The NWK network can also be a corporate network connecting the different sites of the same company. The NWK network can include several virtual private networks deployed on a public network such as the Internet. The NWK network can also be a combination of these different types of networks.

[0110] The management entity 100 comprises the following modules: A module 101 for receiving a request to be processed RQ(V); A module 102 for selecting a processing server SBE in the GP group of servers; A module 103 for transmitting a request to be processed RQ(V) to the processing server SBE.

[0111] The processing server SBE comprises the following modules: A module 201 for receiving the request to be processed RQ(V) transmitted by the management entity 100; A module 202 for reading in the session base SDB information INF relating to the current session; A module 203 for processing the request to be processed RQ(V) using the information INF read.

[0112] The management entity 100 has the hardware architecture of a conventional computer. It includes in particular a processor, a RAM type random access memory and a read-only memory such as a Flash, ROM type memory (not shown in the figure) as well as input-output devices such as, in certain cases, keyboards and / or screens (not shown in the figure), and network ports allowing communication with other entities and servers using the NWK communication network.

[0113] In particular, the management entity 100 can communicate with IP telephones such as the TEL1 telephone. The management entity 100 can be, for example, a router responsible for the communications of a fleet of IP telephones. The management entity 100 is then located at the input of the IP telephony requests sent by the IP telephones to the SYS system. The management entity 100 can then comprise a load balancing server, or a DNS server, or any other server making it possible to receive and direct IP telephony requests.

[0114] The SBE processing server also has the hardware architecture of a conventional computer. It includes a processor, RAM and read-only memory such as Flash or ROM (not shown in the figure), as well as input-output devices such as, in some cases, keyboards and / or screens (not shown in the figure), and network ports for communicating with other entities and servers using the NWK communication network.

[0115] The SDB session database is a database that runs on a database server that also has the hardware architecture of a conventional computer. The SDB session database is also accessible via the NWK network to all entities and servers of the SYS system that need to access it for the purposes of the invention. The SDB session database can be implemented by a single database, or by a duo of databases, or by a larger quantity of databases, in order to be available for reading or writing to the different entities and servers of the SYS system that need it. The SDB session database can be a high-availability database cluster.The SDB session database can use cross-database data replication algorithms to ensure high availability even in the presence of failures of individual databases included in the cluster included in the SDB session database.

[0116] The servers underlying the execution of the management entity 100, the session database SDB and the various servers SBE, SBE', SBE'', AS, AS', AS'', MGW, MGW', MGW'' of the SYS system may be hardware servers of the SYS system connected to each other by the NWK network or, if the SYS system is deployed in a cloud computing architecture, they may be virtual machines deployed on demand on hardware servers provided by a cloud infrastructure not forming part of the SYS system as such. Containers may be used to facilitate the deployment on a cloud infrastructure of the entities, databases and servers of the SYS telephony system.Mixed architectures of the SYS system can be deployed comprising on the one hand hardware servers belonging to the SYS system and on the other hand infrastructure resources outside the SYS system, but controlled by it to run other servers of the SYS system.

[0117] The SYS IP telephony system includes several types of servers to provide a complete IP telephony service.

[0118] For example, an IP telephony system includes registrar servers that register new IP phones connecting to the SYS system and to which other systems to send IP telephony requests that leave the SYS system. These directory servers are not shown in the.

[0119] An IP telephony system will also include servers that are session border controllers, often referred to by the acronym SBC. SBC servers are located at the border of IP telephony networks and are responsible for communications with elements outside these networks, or from one IP telephony network to another. In particular, SBC servers are those that provide communications with terminals, i.e., IP telephones, which are considered to be outside the IP telephony network itself. SBC servers can be seen as comprising, on the one hand, a component that manages the signaling aspects, called the session border element, often referred to as SBE (session border element), and on the other hand, a component that manages the media aspects, namely a multimedia gateway, often referred to as MGW (media gateway).

[0120] The SYS IP telephony system shown in the example comprises three SBE servers, SBE', SBE'', which are border session elements of the SYS system, and three MGW servers, MGW', MGW'', which are multimedia gateways.

[0121] An IP telephony system will also include servers that are application servers, often referred to by the acronym AS, which provide the various types of telephone services provided in IP telephony. For example, AS servers are used to manage services such as call forwarding, call waiting, three-way conferencing, playing music when ringing, or any other telephone service.

[0122] The SYS IP telephony system represented in our example includes three servers AS, AS', AS'' which are application servers.

[0123] The GP group of processing servers comprises, in the example of the architecture of the SYS system represented in the, the servers which are border session elements, namely the servers SBE, SBE', SBE'' but this distribution is only an example of embodiment and is not systematic in all the examples of embodiment of the invention. Here, in the example of the, all the SBE servers belong to the GP group among which the RQ(V) requests for telephony over IP will be allocated.Since the SBE servers are those in charge of the requests that enter the SYS IP telephony system, coming from IP phones such as TEL1 or from other IP telephony networks, this means that, for all requests entering the SYS system, the invention will be implemented and an allocation will be made request by request to the SBE servers, even within a single IP telephony session, whereas this will not be the case for requests to the AS application servers or the MGW multimedia gateways. However, this embodiment is only one possible embodiment among others. For example, the invention can be implemented only for requests within the SYS system to the AS application servers, or for a GP group grouping the SBE border servers and the AS application servers.Similarly, the invention can also be applied to a group comprising MGW multimedia gateways.

[0124] The operation of the invention, in the exemplary embodiment shown in the, is as follows.

[0125] The IP telephone TEL1 sends an IP telephony request RQ(V) to the SYS IP telephony system.

[0126] This request will generally be a request according to the SIP protocol, which is very widely used in the field of IP telephony. However, it can be a request according to the H.323 protocol, which is also used in IP telephony, or it can be a request according to another protocol, which could be, for example, a future evolution of the SIP protocol, or another protocol replacing SIP in the long term.

[0127] As is customary for communication protocol requests, the content of the RQ(V) request can be separated into a header, which includes data used by the communication protocol, and a payload, which includes data transmitted to other participants in the protocol. These notions of header and payload are common in the field of communication protocols and not limited to the field of IP telephony. The RQ(V) request includes a value V taken by a given field of the request header.

[0128] The RQ(V) request is sent by the IP telephone TEL1 to the SYS IP telephony system using the NWK communication network. The RQ(V) request is received by the management entity 100 at the receiving module 101.

[0129] The management entity 100 may be, for example, a router responsible for routing IP communications entering the SYS IP telephony system. The management entity 100 may comprise a load balancing system, a DNS domain name server, or a virtual IP address mechanism. The IP telephones processed by the SYS system, rather than being assigned to a fixed SBE server, have knowledge of an IP address or a domain name which will direct their RQ(V) requests to the reception module 101 of the management entity 100.

[0130] The use of the DNS server or the IP virtual addressing mechanism will then select, from the initial IP address or domain name of the RQ(V) request, an SBE server belonging to the GP group of processing servers. The SBE server is then the server assigned for processing the RQ(V) request. This selection is carried out by the selection module 102 of the management entity 100. This selection will seek to achieve load balancing so that the servers of the GP group are not overloaded by an excess of requests to be processed at a given time. Load balancing may be achieved by random selection, or by using a round-robin algorithm, or any other appropriate technique.

[0131] Once the selection has been made, the management entity 100 transmits, using the transmission module 103, the request to be processed RQ(V), for processing, to the assigned server SBE.

[0132] The assigned server SBE receives the RQ(V) request using the reception module 201.

[0133] The assigned server SBE will then read INF information from the session database SDB. This reading is carried out by the reading module 202. This INF information will be used for processing the request RQ(V) by the processing module 203. In the exemplary embodiment shown in the, the processing consists of transmitting the request RQ(V) to the application server AS'. The address of the application server AS', which allows the server SBE to carry out this transmission, can be, for example, the INF information read previously.

[0134] In exemplary embodiments, the RQ(V) request comprises a field, for example a header field, which takes a given value V such that this value V is the same for the request to be processed RQ(V) and for a previous request which took place in the same IP telephony session. This value V is used as a key to retrieve the INF information useful for processing the RQ(V) request in the session database SDB.

[0135] For example, in the SIP protocol, a SIP request will include From: and To: fields in its header, which take as values ​​the addresses of the senders and recipients of the requests. These values ​​will be the same in a given IP telephony session. However, these values ​​are not sufficient to find a current session since the same senders and recipients may have carried out several successive sessions and even have telephony sessions in parallel.

[0136] The Call-ID: field identifies a SIP dialog. This notion of dialog allows you to find requests that precede the request to be processed in a current IP telephony session, but not all of the requests in the current session. Indeed, in SIP, processing servers are generally so-called B2BUA servers, an acronym for back to back user agent. This means that a processing server, when it receives a request from a first terminal, will create a new dialog with another terminal and back up this new dialog created with the already existing dialog between the first terminal and the processing server. A SIP IP telephony session then includes at least two dialogs, the requests belonging to the same dialog having the same value for the Call-ID: field.

[0137] When the value V is the one taken by the Call-ID: field, it allows to find the INF information of the requests of a given session belonging to the same dialog, for example those between the SBE processing server and a given TEL1 IP telephone. But the requests corresponding to the other dialogs of the same session do not have the same Call-ID: field value. The INF information can however be found in the SDB session database if, when a new dialog belonging to a given session is created, the correspondence between the Call-ID: identifier of the first dialog and that of the created dialog is recorded in the SDB session database.

[0138] In the majority of embodiments, the processing server SBE comprises a module 204 (not shown in the) for recording in the session base SDB information INF' (not shown in the) relating to the processing that the processing server SBE has just carried out. This information may be, for example, the address of the server AS' to which the request RQ(V) has just been transferred for subsequent processing, in order to be able to contact the same server AS' again when processing a subsequent request. This may be a dialogue identifier Call-ID: which has just been created so that the session base SDB can make the link between all the dialogues belonging to a current IP telephony session and can provide all the useful information from a single value V taken by a field Call-ID:.

[0139] In other embodiments, the protocol used by the SYS IP telephony system is not the SIP protocol or is an evolution of the SIP protocol. In such an evolution, it is possible to define a field that would correspond to the identification of a telephony session and no longer only of a dialogue between a server and a terminal or between two servers. For example, it is possible to define ad hoc fields in certain SIP implementations, by using a field title whose initial letter is 'X'. Such an ad hoc field may be a session identifier. The use of a session identifier would simplify the implementation of the methods according to the invention by making it possible to find all the relevant INF information in the session database SDB by using the value V taken by this field as a query key in the session database SDB.

[0140] In the example presented in the, only SBE servers belong to the GP group of processing servers for which the RQ requests are dynamically allocated by the management entity 100. It is possible to imagine an implementation in which another management entity would allocate the requests to the AS application servers or the MGW multimedia gateways according to the same principle.

[0141] The, for its part, represents an example of message exchanges carried out during an IP telephony session established using the methods according to the invention.

[0142] The example shown in is a simplified version of message exchange using the SIP protocol.

[0143] In this example, the IP telephone TEL1 issues a SIPInviteINV request to initiate an IP telephony communication session. In this case, the IP telephone TEL1 wishes to call the IP telephone TEL2. The telephone TEL1 sends the INV request to the management entity 100 which is for example an input router of the IP telephony system SYS. The telephone TEL1 therefore does not need to know a border server dedicated to it, but simply an IP address corresponding to the input router of the system SYS.

[0144] As seen previously, the management entity 100 will assign the INV request to one of the three processing servers SBE, SBE', SBE'' which belong to the GP group of processing servers. In this case, the management entity 100 transmits the INV request to the processing server SBE.

[0145] The SBE processing server will then perform an RD read operation of information in the SDB session database which belongs to the SYS system, in addition to the GP group of the SBE processing servers, SBE', SBE''. In this case, as the INV request is the initial request of an IP telephony session, there will be no information to read in the SDB session database corresponding to this session.

[0146] The SBE server will then proceed with the actual processing of the INV request. This processing includes, on the one hand, transferring the INV request to the IP phone TEL2, which is the IP phone that the IP phone TEL1 wishes to call, and on the other hand, transferring the INV request to the MGW multimedia gateway.

[0147] The latter also belongs to the SYS IP telephony system, without belonging to the GD group of the SBE, SBE', SBE'' servers. The MGW gateway will then proceed to create a part of a multimedia channel, attached to the IP telephone TEL1, represented in the by two thick lines. This part, attached to the IP telephone TEL1, will be completed by a part attached to the IP telephone TEL2 to form the actual telephone link between the two IP telephones TEL1 and TEL2. The final establishment of the telephone link, apart from the signaling itself, and the transport of data within the link is traditionally done using the RTP protocol.

[0148] After processing the INV request, the SBE server will record WT in the SDB session database information relating to the current session in order to facilitate subsequent processing.

[0149] The information recorded WT will for example include the addresses and identities of the servers (here SBE and MGW) which participate in the processing of the INV request. The identities and addresses of the telephones concerned by the request (here TEL1 and TEL2) can also be recorded. In addition, the value taken by the Call-ID field will also be recorded, and will even serve as a key in the SDB database, in several embodiments, to retrieve the relevant recorded information. If the SBE server, to process the INV request, is required to create a new dialog, which is usual when the SBE server is used in a B2BUA mode (back-to-back mode, or back to back user agent), it will be able to record WT in the SDB session database an association between the value of the Call-ID field of the initial request and that of the Call-ID field of the new dialog created.In this way, when another server processes a new request related to this created dialog, consulting the association recorded in the SDB session database will allow it to retrieve the value of the Call-ID field of the first dialog and therefore also the relevant information of the requests of this first dialog. This information is useful because the first dialog and the following dialogs are indeed part of the same IP telephony session.

[0150] The TEL2 IP telephone, for its part, receives the INV request transmitted by the SBE server. The TEL2 IP telephone will then carry out actions not shown in the figure. For example, it will emit a ring tone to its user. If the user picks up and accepts the call, the TEL2 IP telephone will emit an OK request. This request is sent to the management entity 100. The latter will assign this OK request for processing to a processing server in the GP group, in this case the SBE processing server.

[0151] We just see that, for the same IP telephony session, two separate processing servers are requested.

[0152] The SBE processing server will then read RD from the SDB session database the relevant information to process the OK request. Such information could be, for example, an address allowing it to contact the MGW multimedia gateway that was previously requested in the session.

[0153] The processing by the SBE' server will then include the transfer of the OK request on the one hand to the IP telephone TEL1 and on the other hand to the MGW multimedia gateway. The latter will carry out the expected processing which consists of completing the telephone link itself, part of which had already been built, attached to the IP telephone TEL1. The MGW multimedia gateway here builds the part attached to the IP telephone TEL2 and connects these two parts of the link. The telephone link thus built can carry the speech signal between the IP telephones TEL1 and TEL2, a signal represented by the sinusoidal curve between the two thick lines.

[0154] In other words, at this stage, a telephone call takes place between the IP telephones TEL1 and TEL2, a call whose setup required the intervention of two separate processing servers SBE and SBE', whereas in standard IP telephony, only one processing server would intervene for a given session.

[0155] The SBE processing server will then record WT in the SDB session database the relevant information for subsequent processing of the current IP telephony session.

[0156] The IP telephone TEL1 will then send a BYE request. This request corresponds to a hang-up action on the part of the user of the IP telephone TEL1. The BYE request is sent by the telephone TEL1 to the management entity 100. The latter will assign the BYE request to a processing server belonging to the GP group, in this case the SBE processing server. Finally, three separate processing servers belonging to the GP group will have been requested to carry out the processing of the requests for the telephony session described here.

[0157] The SBE processing server will read RD from the SDB session database the information necessary to process the BYE request. This processing consists of transferring the BYE request to the IP telephone TEL2 on the one hand and to the MGW multimedia gateway on the other. This will destroy the telephone link established between TEL1 and TEL2, which is represented by a cross on the link symbol constructed previously. The MGW gateway will thus recover the hardware, memory or energy resources that were mobilized by the establishment of the IP telephone link between the TEL1 and TEL2 telephones. The SBE server, after its processing, makes a WT record of relevant information in the SDB session database.

[0158] The IP telephony session between the two phones TEL1 and TEL2 is thus completed and has involved three different processing servers SBE, SBE' and SBE'' for signaling processing, instead of a single server in charge of the session. These servers SBE, SBE' and SBE'' are stateless servers that use information present in the SDB session database to carry out the requested processing.

[0159] The, for its part, represents another example of architecture of a SYS IP telephony system according to the invention.

[0160] In this example of SYS system architecture, the SYS system processing servers are distributed in three groups GP, GP' and GP'', excluding the media gateways MGW, MGW', MGW'' as well as a directory server RGR.

[0161] The first GP group includes a variable number of SBE servers, SBE', SBE''. The presence of three dots symbolizes the variation over time of the number of servers in this group. The servers in this GP group are border session elements. In this example, they are the servers responsible for processing requests from IP phones in a pool processed by the SYS system, and also for sending requests to them. The GP group of processing servers has an SDB session database as well as an RTR router. The RTR router, in this example architecture, fulfills the role of a management entity that will assign requests one by one to the servers in the GP group. The SDB session database is, in this example architecture, dedicated to requests for information from the SBE, SBE', SBE'' servers. The number of SBE, SBE', SBE'' servers varies over time.Since the servers are responsible for processing requests from the IP phones in the fleet managed by the SYS system, the needs are lower during the night, for example. In this case, the variation over time in the number of SBE, SBE', SBE'' servers allows for resource savings.

[0162] The second group GP' also includes servers SBE''', SBE'''', SBE''''', i.e. border session elements, but these servers, in this example, are responsible for receiving and transmitting telephony requests to other telephony systems. For example, a call request from a telephone TEL1 (not shown in the figure) in the pool managed by the system SYS to a telephone TEL2 (not shown) outside this pool could be processed in the following way: A request from the pool of IP telephones managed by the system SYS, like all requests from the pool of telephones, is addressed to the router RTR which assigns it to a server SBE, SBE', SBE'' in the group GP; The request is assigned by the router RTR to the server SBE in the group GP; This consults the directory server RGR which indicates that the telephone TEL2 is not managed by the system SYS;It then addresses the request to the GP' group, grouping the SBE servers in charge of communicating with the other IP telephony systems; At the end of the processing by the SBE server, it enters in the SDB session database relevant information for subsequent processing, for example the association between the SIP dialogue initiated by the TEL1 telephone and the SIP dialogue initiated by the SBE server to transmit the request to an external TEL2 telephone; The RTR' router, at the input of the GP' group, will then assign the request to a server, for example SBE''', of the GP' group, which will process it by addressing it outside the SYS system; The SBE''' server will enter in the SDB' session database the information which will allow, when another server of the GP' group receives the response to its transmitted request, to retransmit it to the RTR router of the GP group and in general to find in the SDB' database the information necessary for processing the response;When the RTR router receives a return request, it will assign it to a server in the GP group, which has no reason to be the SBE server that processed the initial request; if this server is, for example, an SBE, it will query the SDB session database to find the relevant information, for example the association between dialogs created by the SBE server in processing the initial request.

[0163] The GP's group servers are also variable in number in order to save resources when it is likely that the number of requests will decrease or increase.

[0164] The third group GP'', for its part, includes the application servers AS, AS', AS'', again in variable numbers.

[0165] The application servers AS, AS', AS'' grouped in the GP'' group are responsible for processing requests relating to telephony services, for example three-way calls, conference calls, call transfers or others. Traditionally, these servers are differentiated and each dedicated to a given service. This organization therefore reserves resources in advance since, for each service, at least one dedicated server is required. With in our example undifferentiated servers to process telephony services, in variable number, grouped in the GP'' group, it is possible to achieve significant savings in energy and material resources.

[0166] When, in the processing of a request, it is necessary to request one of the AS servers, this is addressed to the router RTR'' at the input of the GP group'' which will carry out the allocation of the request to an AS, AS' or AS'' server among the GP group''. The allocated server will then use, in our example, the session database SDB'' to read the information relevant to the processing of the request and record if necessary information relevant to the processing of subsequent requests in the session.

[0167] In our example, the multimedia gateways MGW, MGW', MGW'' are not grouped into a dedicated group. They are therefore assigned to the creation of telephone connections for a given fleet. This operating mode, close to the current mode, can be justified by the nature of the processing carried out by the multimedia gateways which are more attached to the hardware equipment of the fleet than are the other processing servers. The same is true for the directory server RGR. The invention therefore makes it possible to build mixed architectures of an IP telephony system SYS where servers can be grouped into groups GP, GP', GP'' and organized into sets of variable size in order to best adapt to variations in demand and where other servers will be kept in fixed numbers, assigned to hardware elements, and this according to the nature of the tasks carried out by the processing servers.

[0168] However, the invention can also be used in an architecture in which all the processing servers are grouped together, are undifferentiated, and carry out differentiated processing by calling programs specialized for given processing. Such an architecture, made possible by the invention, has the advantage of using undifferentiated hardware for all the servers and techniques for deploying and varying the servers according to the load that are not specific to the field of IP telephony. Other intermediate architectures are possible where, for example, the SBE border session servers are grouped into a single group and are not differentiated, as in our example, between servers dedicated to relations with the telephones in the park on the one hand and to relations with the other telephony systems on the other hand.

[0169] Finally, it should be noted here that, in this text, the term "module" can correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or, more generally, to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).

Claims

Method for processing a telephony request (RQ), called a request to be processed, belonging to a telephony session, called a current session, by a processing server (SBE) belonging to a group (GP) of servers, characterized in that the request to be processed (RQ) includes a value (V), called a key value, and in that the method comprises the following steps: Reception of the request to be processed (RQ); Reading in a database (SDB) information (INF) relating to the current session accessible using the key value (V); Processing of the request to be processed (RQ) using the information (INF) read. Processing method according to claim 1 characterized in that the key value (V) is equal to a value included in a previous request to be processed belonging to the current session. Processing method according to one of claims 1 or 2 characterized in that the number of processing servers belonging to the group (GP) of servers varies over time. Processing method according to one of claims 1 to 3, characterized in that the method further comprises a step of recording in the database (SDB) information (INF) resulting from the processing by the assigned server (SBE) of the request to be processed (RQ), said information (INF) being recorded in association with the key value (V). Processing server (SBE) of an IP telephony request (RQ), called request to be processed, belonging to an IP telephony session, called current session, said processing server (SBE) belonging to a group (GP) of servers, characterized in that the request to be processed (RQ) includes a value (V), called key value, which and in that the server (SBE) comprises the following modules: A module (201) for receiving the request to be processed (RQ); A module (202) for reading in a database (SDB) information (INF) relating to the current session accessible using the key value (V); A module (203) for processing the request to be processed (RQ) using the information (INF) read. Computer program capable of being implemented by a processing server (SBE) of a telephony request (RQ), the program comprising code instructions which, when executed by a processor, carry out the steps of the processing method according to claim 1. Data carrier, on which is recorded a computer program comprising a sequence of instructions for implementing the processing method according to claim 6 when loaded into and executed by a processor.

Images