Method for managing the allocation to an IP telephony request processing server

Abstract

Method for managing the allocation to a processing server of IP telephony requests The invention relates to a method for managing, by a management entity, the allocation to a processing server, belonging to a group of servers, of IP telephony requests, called requests to be processed, belonging to the same IP telephony session, characterized in that during the IP telephony 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 the allocated server, for processing. Figure 1

Description

Title of the invention: Method for managing the allocation to a server for processing IP telephony requests Technical field

[0001] The technical field is that of IP telephony.

[0002] More specifically, the invention relates to a method for managing the allocation to a processing server of IP telephony requests belonging to an IP telephony session as well as to associated methods for processing an IP telephony request by a processing server and for managing an IP telephony session by an IP telephony system. The invention also relates to a management entity, a processing server, and an IP 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 links, between two or more telephone terminals. A calling terminal requests the opening of a telephone link 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 link between the calling terminal and the called terminal, collaborating with other servers to establish the link. Once the link 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) making it possible to establish the connection are traditionally called signaling protocols.

[0005] These concepts first appeared in traditional telephony, for example that using the switched telephone network (PSTN, called Plain Old Telephone System in English, or POTS) or, more recently, with the integrated services digital network (ISDN, called Integrated Services Digital Network in English, or ISDN). Telephone terminals are then simply called telephones and the servers which establish telephone connections are switches, and in particular automatic branch exchanges from the development of digital telephony. Access from terminals to servers was traditionally done 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, codec negotiation (abbreviated 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 can 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 signaling, call transfer, caller ID, call blocking or any other telephony service. In IP telephony, telephone terminals are conventionally called IP telephones. State of the art

[0008] Telephony, whether it is traditional telephony or IP telephony, requires the implementation of a stateful communication protocol (translation of the English statefulprotocol), that is to say that the establishment of telephone communications is done by taking into account a state of the telephone terminals which will evolve throughout the telephone communication. Obviously, a terminal which 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 will therefore be able to respond positively to a new telephone communication request and will then go back to the busy state. This notion of stateful protocol is opposed to that of stateless communication protocol (translation of the English statelessprotocol) in which the participants in the protocol only exchange questions and answers. without having any state change. 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.

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

[0010] Similarly, the request processing servers include on the one hand application servers (translation of the English application servers), often designated by the acronym AS, which provide the different types of telephone service provided in IP telephony and on the other hand session border controllers (translation of the English session border controllers), often designated by the acronym SBC. The SBC servers are located at the border of the IP telephony networks and it is they which ensure communications with elements outside these networks, or from one IP telephony network to another. In particular, the SBC servers are those which ensure communications with the terminals, that is to say with the 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 handles the signaling aspects, called a session border element, often referred to as SBE (acronym for session border element) and on the other hand a component that handles the media aspects, namely a media gateway, often referred to as MGW (acronym for media gateway).

[0011] In the field of IP telephony, the distribution of requests from telephone terminals to IP telephony request processing servers traditionally takes place in the following manner: 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 pool of IP telephones.

[0012] This situation has drawbacks.

[0013] First, it requires reserving a large amount of hardware resources and computing. If a server of a given size is sized to manage the telephone communications of 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 telephones, 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.

[0014] Furthermore, this situation does not allow for the easy addition of new terminals. Each time, a server and its duplicate must be added to accommodate new servers. The IP telephone allocation plan for SBC servers must also be redefined to prevent a new SBC server from supporting only a few terminals when it is launched, which would not relieve the load on the SBC servers already deployed.

[0015] Then, this situation requires making assumptions about the rate of use that IP telephones will make of the telephone service in order to determine how many servers must be provided for a given fleet. These assumptions may be erroneous 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.

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

[0017] 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 between 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.

[0018] The invention improves the situation. Statement of the invention

[0019] According to a first functional aspect, the invention relates to a method for managing by a management entity the allocation to a processing server, belonging to a group of servers, of IP telephony requests, called requests to be processed, belonging to the same IP 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.

[0020] Thanks to the invention, the telephone terminals in IP telephony are no longer assigned to a predefined IP telephony server. For this, the IP telephony requests sent 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 IP telephones. In addition, a processing server is assigned to a 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 the requests on demand. In the event of a failure of a processing server in the group, the other servers in the group will be able to replace it.It is therefore no longer necessary to provide a backup server for all the IP 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.

[0021] According to a particular embodiment of this first 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.

[0022] Thanks to this embodiment, processing throughout an IP telephony session by different servers is facilitated. The 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 carried out by other servers. The transmission of the key value in the request to the assigned server helps to achieve this goal.

[0023] Other embodiments are possible. For example, the session base 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 the processing of a larger amount of data but has the advantage of simplifying the operation of the session base which only has to record all the processed requests and provide them on request.

[0024] According to another particular embodiment of this first 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 IP telephony session.

[0025] Thanks to this mode, the different requests of the same IP telephony session are a priori processed by different servers in the group of servers. In this way, unlike the situation in the prior art, a processing server is not responsible for an end-to-end session, which implies 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.

[0026] Furthermore, in the invention, a processing server is a stateless server, which does not have to memorize the state of an IP 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 IP 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 IP telephony service in general.

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

[0028] In the general case, a different server will be assigned to the request to be processed than the one that was assigned to the previous request in the telephony session. But, this does not may not be the case for the initial request of the telephony session. Thanks to this aspect of the invention, this particular case is addressed.

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

[0030] Thanks to this mode, the group of processing servers that will carry out the processing of IP telephony requests is not fixed, depending on the number of IP 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 the IP telephony needs decrease. Thus, the energy and material resources mobilized by the processing servers are saved.

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

[0032] IP telephony requests are generally sent by IP telephones. In this embodiment, it is specified that the processing servers are not allocated using the identity of the sending IP telephone, because this would amount to assigning a processing server to a given pool of IP telephones. Here, an IP telephone that sends an IP 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 IP 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 IP telephones in advance.

[0033] 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.

[0034] 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 very different. In other words, several different processing servers will be assigned to the different requests throughout the IP telephony session.

[0035] 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.

[0036] 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 ultimately be more efficient, for example by assigning the requests of a given session, or of a part of a given session, to a single processing server. In this case, there is still a 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.

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

[0038] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding 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.

[0039] The management entity can be a load balancer which will ensure that the IP telephony requests are well distributed between the different processing servers of the group. Thanks to this embodiment, 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.

[0040] 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.

[0041] With this embodiment, a simple way of achieving load balancing is proposed. For this, the allocation of a processing server to a request is done by a random draw. This technique is easy to implement and achieves an appropriate distribution of requests between servers.

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

[0043] A round-robin algorithm is a classic load balancing algorithm. With this embodiment, a known load balancing algorithm is used in the field of IP telephony. One advantage is that it is possible to benefit from technologies known elsewhere in this field, and therefore to reuse existing software. The round-robin algorithm allows for efficient distribution and will therefore also improve the use of resources by the processing servers. Such 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.

[0044] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding 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.

[0045] 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, an IP telephone will address a request to a domain name using the IP protocol, and it is the domain name server that directs the request 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 request. This embodiment therefore makes it possible to obtain an alternative embodiment of the invention. The different load balancing techniques can be integrated into the domain name server in order to optimize the distribution of request processing between servers.

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

[0047] With this embodiment, an alternative is provided for the allocation of requests. The virtual IP address mechanism is lighter than the deployment of a domain name server and also allows a request to be directed 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.

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

[0049] According to another mode of implementation of the invention, which may be implemented alternatively or cumulatively with the preceding modes, the key value is identical for all the requests to be processed belonging to the same IP telephony session.

[0050] Thanks to 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 of the group. But the presence of such information, which constitutes a session identifier, makes it possible to facilitate the subsequent processing of the requests by the different servers.

[0051] According to a second functional aspect, the invention relates to a method for processing an IP telephony request, called a request to be processed, belonging to an IP telephony session, called a session in progress, by a processing server, called an assigned server, belonging to a group of servers, characterized in that the method comprises the following steps: • Receipt of the request to be processed transmitted by a management entity responsible for allocating requests to be processed for the current session; • Reading information relating to the current session from a database, called a session database; • Processing of the request to be processed using the information read.

[0052] Thanks to this second aspect of the invention, the actual processing of IP telephony requests is carried out. 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 the previous requests that took place in the same session. This functionality allows the processing of an IP telephony protocol, which is by nature a stateful protocol, to be carried out using a stateless method in which a telephony request is assigned, including in certain modes randomly, to a server among a group of servers. The processing of the request is then done according to the classic functionalities of an IP telephony processing server, once the information relating to the session has been obtained by the server.

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

[0054] 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 IP telephones.

[0055] Another advantage of the invention is the robustness of the solution. If a server fails in the group of processing servers, 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 the conventional operation of IP telephony, it is enough for one server to fail, then its backup server, for an entire fleet of IP telephones to be deprived of telephony service.

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

[0057] According to a particular embodiment of this second aspect of the invention, the request to be processed includes a field which takes a value, called the 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 information read in the session base is accessible thanks to the key value.

[0058] Thanks to this first mode of the second functional aspect of the invention, a method for finding information relating to the session is given. For this, a key value is identified which will be found from the request to be processed in a previous request of the current session. Step by step, it is possible to find the information necessary for processing a request to be processed. These values ​​are found for example in the header fields of the requests according to the SIP protocol. Session database programming allows the extraction of 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 allow this information to be brought back step by step.

[0059] 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 IP telephony session and reading in the session database does not provide any information.

[0060] 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 an IP telephony session. The session base may 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.

[0061] According to another particular embodiment of this second aspect 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.

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

[0063] 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 session database information relating to the processing by the assigned server of the request to be processed, said information being accessible using the key value.

[0064] Once the processing has been carried out, it is useful, in the general case, for the processing server which has just carried out the processing of an IP telephony request to enter in the session database information useful for the subsequent processing of requests which will relate to the same session. In this way, the rest of the processing necessary to complete the session can be carried out by other processing servers than the one which has just carried out the request. The information useful for the processing subsequent requests will then be accessible using the key value which will be found for example by the following request of the same session.

[0065] This operation is however not a necessary operation in all cases and can be omitted depending on the nature of the IP telephony request. For example, once an IP telephone link is established, there is a multimedia data transfer channel between two IP telephones (at least), i.e. a data link managed by multimedia servers. Let us suppose that an IP telephony request consists of changing a parameter of this link, for example a parameter relating to sampling, or to data latency or to any other aspect managed by the multimedia servers. The processing of the request will then consist of sending to 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 to save the memory and time resources that would have been wasted by making this recording.

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

[0067] Thanks to this embodiment, the processing of the IP 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 makes it possible to deduce that this request creates the session and that there has not been a previous request which could have left information necessary for the processing of the current request.

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

[0069] 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 IP 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 ('single point of failure'). If the session database no longer functions, the processing servers can no longer retrieve information relating to the sessions and can no longer process the requests. To greatly reduce the probability of this risk occurring, the functionality of the session database is carried out, in this mode, not by a single database, but by a high-availability database cluster. This implementation therefore greatly reduces the probability of unavailability of the IP telephony service caused by unavailability of the session database.

[0070] According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding 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 IP telephony session.

[0071] According to another mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous modes, the key value is identical for all the requests to be processed belonging to the same IP telephony session.

[0072] Thanks to 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 of the group. But the presence of such information, which constitutes a session identifier, makes it possible to facilitate the processing of the requests by the different servers.

[0073] According to a third functional aspect, the invention relates to a method for managing an IP telephony session, called the current session, by an IP telephony system, said system comprising a management entity responsible for assigning an IP telephony request, a group of processing servers, and a database, called the session database, the current session comprising IP 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 an assigned server processes a request to be processed by performing the following steps: • Receipt of the request to be processed transmitted by the management entity; • Reading information relating to the session in the session database course ; • Processing of the request to be processed using the information read.

[0074] Thanks to this third functional aspect of the invention, the complete processing of an IP telephony session is carried out by an IP telephony system according to the invention. A request belonging to an IP telephony session is allocated by a management entity included in the system to a server belonging to a group of servers included in the system. These servers are allocated by the management entity to balance the load, without taking into account a priori the state of the session. telephony session in progress. In addition, processing servers are also stateless servers. A given server will not process an entire telephony session but one or more requests within the session, depending on the allocation made by the management entity, for example according to load balancing needs. The session-related information needed to process the request is then retrieved by the processing server from the session database.

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

[0076] According to a particular embodiment of this third aspect of the invention, a request of the current session 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 information read in the session base is accessible thanks to the key value.

[0077] Thanks to this first mode of the third functional aspect of the invention, the recovery in the session database of information relating to the session is facilitated. A query has a key value which makes it possible to find, in the session database, step by step, the information relating to the processing carried out on the previous queries of the same session.

[0078] 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 session database of information relating to the processing by the assigned server of the request to be processed, said information being accessible using the key value.

[0079] Once the processing has been carried out, it is useful, in the general case, for the processing server which has just carried out the processing of an IP telephony request to enter in the session database information useful for subsequent processing of requests which will relate to the same session. In this way, the rest of the processing necessary to complete the session can be carried out by other processing servers than the one which has just carried out the request. The information useful for subsequent processing will then be accessible thanks to the key value which will be found for example by the following request of the same session.

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

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

[0082] Thanks to these embodiments, a value is found identically in all the requests of the session which is managed by the IP telephony system. Such a value serves as a session identifier and makes it possible to simplify the processing carried out by the session base to provide the information useful for processing the requests of the session.

[0083] According to a first 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 IP telephony requests, called requests to be processed, belonging to the same IP telephony session, called current session, 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;

[0084] 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.

[0085] According to a second material aspect, the invention relates to a server for processing an IP telephony request, called a request to be processed, belonging to an IP telephony session, called a current session, said processing server belonging to a group of servers, characterized in that the server comprises the following modules: • A module for receiving the request to be processed transmitted by a management entity responsible for allocating the requests to be processed for the current session; • A module for reading information relating to the current session from a database, called a session database; • A module for processing the request to be processed using the information read.

[0086] According to a particular implementation mode of this second hardware 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 information read in the session base is accessible thanks to the key value.

[0087] According to another particular embodiment of this second hardware aspect, the invention relates to a processing server further comprising a module 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.

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

[0089] 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.

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

[0091] 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.

[0092] 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. Furthermore, 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

[0093] 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:

[0094] [Fig.l] represents an IP telephony system comprising a management entity according to the invention, a group of processing servers according to the invention and a database, called a session database.

[0095] [Fig.2] illustrates an example of message exchanges carried out during a tele IP telephony established using the methods according to the invention.

[0096] [Fig.3] represents another example of architecture of an IP telephony system according to the invention. Detailed description

[0097] [Fig.l] 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, called a session database; and other servers AS, AS', AS”, MGW, MGW' and MGW”. [Fig.l] represents an exemplary embodiment of the invention among other possible embodiments.

[0098] [Fig.l] also shows IP telephones, including one called TEL1, and an NWK communication network.

[0099] The NWK network is a public or private IP (Internet Protocol) network, which connects the SYS IP telephony system and other similar systems as well as IP telephones, including the TEL1 telephone, 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 network or a metropolitan or international network, or a combination of local networks connected to each other 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.

[0100] 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 an SBE processing server in the group GP of servers; • A module 103 for transmitting a request to be processed RQ(V) to the processing server SBE.

[0101] The SBE processing server includes 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 INF information relating to the current session in the SDB session database; • A module 203 for processing the request to be processed RQ(V) using the INF information read.

[0102] The management entity 100 has the hardware architecture of a conventional computer. It includes in particular a processor, a RAM of type RAM and read-only memory such as Flash memory, 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 allowing communication with other entities and servers through the NWK communication network.

[0103] In particular, the management entity 100 can communicate with IP telephones such as the TELE 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.

[0104] The SBE processing server also 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.

[0105] 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 within the cluster included in the SDB session database.

[0106] The servers underlying the execution of the management entity 100, the session base 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 at the application on hardware servers provided by a cloud infrastructure (translation of the English 'cloud infrastructure') not part of the SYS system as such. Containers (translation of the English 'containers') can 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.

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

[0108] For example, an IP telephony system includes registrar type servers that allow new IP telephones connecting to the SYS system to be registered and to know to which other systems IP telephony requests that leave the SYS system should be addressed. These directory type servers are not shown in [Fig.l].

[0109] 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. with 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 handles the signaling aspects, called a session border element, often referred to as SBE (acronym for session border element) and on the other hand a component that handles the media aspects, namely a media gateway, often referred to as MGW (acronym for media gateway).

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

[0111] 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.

[0112] The SYS IP telephony system shown in [Fig. 1] comprises in our example three servers AS, AS', AS” which are application servers.

[0113] The GP group of processing servers comprises, in the example of architecture of the SYS system represented in [Fig.l], 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 [Fig.l], 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.

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

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

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

[0117] As is customary for communication protocol requests, the content of the RQ(V) request can be separated between a header, which includes data used by the communication protocol and a payload, which includes the 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.

[0118] 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 reception module 101.

[0119] The management entity 100 may be, for example, a router which is responsible for routing the 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.

[0120] 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 a random draw, or by using a round-robin algorithm, or any other appropriate technique.

[0121] 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.

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

[0123] The assigned server SBE will then read information from the session database SDB INF. This reading is carried out by the reading module 202. This INF information will be used for processing the RQ(V) request by the processing module 203. In the example embodiment shown in [Fig.l], the processing consists of transmitting the RQ(V) request 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.

[0124] In exemplary embodiments, the request RQ(V) 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 information INF useful for processing the request RQ(V) in the session base SDB.

[0125] For example, in the SIP protocol, a SIP request will include in its header From: and To: fields which take as values ​​the addresses of the senders and destinations. request recipients. 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.

[0126] The Call-ID: field will identify a SIP dialogue. This notion of dialogue makes it possible to find requests preceding the request to be processed in a current IP telephony session, but not all of the requests in the current session. Indeed, in SIP, the 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 dialogue with another terminal and back up this new dialogue created with the already existing dialogue between the first terminal and the processing server. A SIP IP telephony session then includes at least two dialogues, the requests belonging to the same dialogue having the same value for the Call-ID: field.

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

[0128] In the majority of embodiments, the processing server SBE comprises a module 204 (not shown in [Fig.l]) for recording in the session base SDB information INF' (not shown in [Fig.l]) 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:.

[0129] 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 which 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 title of field whose initial letter is 'X'. Such an ad hoc field can 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 SDB session database by using the value V taken by this field as a query key in the SDB session database.

[0130] In the example presented in [Fig.l], 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.

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

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

[0133] In this example, the IP telephone TEL1 sends a SIP Invite INV 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 addresses 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.

[0134] 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.

[0135] The SBE processing server will then perform an RD read operation of information in the SDB session base 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 base corresponding to this session.

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

[0137] 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 part of a multimedia channel, attached to the IP telephone TEL1, re presented in [Fig.2] by two thick lines. This part, attached to the IP phone TEL1, will be completed by a part attached to the IP phone TEL2 to form the actual telephone link between the two IP phones TEL1 and TEL2. The final establishment of the telephone link, apart from the actual signaling, and the transport of data within the link is conventionally done using the RTP protocol.

[0138] After having carried out this processing of the INV request, the SBE server will proceed to the WT recording in the SDB session base of information relating to the current session in order to facilitate subsequent processing.

[0139] The recorded information 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-1D 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 user agent mode), 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.

[0140] The IP telephone TEL2, for its part, receives the INV request transmitted by the SBE server. The IP telephone TEL2 will then carry out actions not shown in [Fig.2]. For example, it will emit a ring tone to its user. If the user picks up and accepts the communication, the IP telephone TEL2 will emit an OK request. This request is addressed 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.

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

[0142] The processing server SBE' will then read RD in the session database SDB the relevant information to carry out the processing of the OK request. Such information may be, for example, an address allowing it to contact the gateway MGW multimedia which was requested earlier in the session.

[0143] 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 multimedia gateway MGW. 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 TELL. The multimedia gateway MGW 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.

[0144] In other words, at this stage, a telephone call takes place between the IP telephones TEL1 and TEL2, a call whose establishment 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.

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

[0146] 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 TELL. 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.

[0147] The SBE processing server will read RD from the SDB session database the information necessary for processing 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 telephones TEL1 and TEL2. The SBE server, after its processing, makes a WT recording of relevant information in the SDB session database.

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

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

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

[0151] The first GP group includes a variable number of SBE, SBE', SBE” servers. The presence of three points 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 telephones 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 of 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 of architecture, dedicated to requests for information from the SBE, SBE', SBE” servers. The number of SBE, SBE', SBE” servers varies over time.As the servers are responsible for processing requests from the IP telephones in the fleet managed by the SYS system, the needs are lower at night, for example. In this case, the variation over time in the number of SBE, SBE', SBE” servers allows for resource savings.

[0152] The second group GP' also includes servers SBE' ' ', SBE' ' ”, SBE'””, namely 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 fleet managed by the system SYS to a telephone TEL2 (not shown) outside this fleet could be processed in the following manner: • A request from the IP telephone pool managed by the SYS system, like all requests from the telephone pool, is addressed to the RTR router which assigns it to an SBE, SBE', SBE” server of the GP group; • The request is assigned by the RTR router to the SBE server of the GP group; • This consults the RGR directory server which tells it that the telephone TEL2 is not managed by the SYS system; • It then sends the request to the GP' group, bringing together the SBE servers responsible for communicating with the other IP telephony systems; • At the end of processing by the SBE server, it enters relevant information into the SDB session database for subsequent processing, for example: 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 in the GP group receives the response to its transmitted request, to retransmit it to the RTR router in 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 a priori reason to be the SBE server that processed the initial request; if this server is, for example, SBE', it will query the SDB session database in order to find the relevant information, for example the association between dialogs created by the SBE server in processing the initial request.

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

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

[0155] 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 make significant savings in energy and material resources.

[0156] 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 base 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.

[0157] 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 mode of operation, 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 RGR directory server. The invention therefore makes it possible to build mixed architectures of a SYS IP telephony system where servers can be grouped into GP, GP', GP” groups and organized into sets of variable size in order to best adapt to variations in demand and where other servers will be kept in a fixed number, assigned to hardware elements, and this according to the nature of the tasks carried out by the processing servers.

[0158] 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.

[0159] Finally, let us point out here that, in the present 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

Claims

1. Method for managing by a management entity (100) the allocation to a processing server, belonging to a group (GP) of servers, of IP telephony requests (RQ), called requests to be processed, belonging to the same IP telephony session, called current session, characterized in that, during the current session, a reception of a request to be processed (RQ) triggers a selection of a processing server (SBE) in the group (GP) of servers, and in that the request to be processed (RQ) is transmitted to the selected server (SBE), called allocated server, for processing.

2. Management method according to claim 1 characterized in that the request to be processed (RQ) includes a field which takes a value (V), 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 in that the request to be processed (RQ) transmitted to the assigned server (SBE) includes the key value (V).

3. Management method according to claim 1 characterized in that the number of processing servers belonging to the group (GP) of servers varies over time.

4. Management method according to claim 1 characterized in that the request to be processed (RQ) comes from an IP telephone (TEL1) and the assigned server (SBE) is selected by the management entity (100) independently of said IP telephone (TEL1).

5. Management method according to claim 1 characterized in that the requests to be processed (RQ) include fields which take a set of values ​​(V) and in that the allocated server (SBE) is selected by the management entity (100) independently of said values ​​(V).

6. Management method according to claim 1 characterized in that the allocated server (SBE) is selected by the management entity (100) so as to distribute the processing load between the different servers of the group (GP) and in that the management entity (100) is a load balancer.

7. Management method according to claim 2 characterized in that the key value (V) is identical for all the requests to be processed (RQ) belonging to the same IP telephony session.

8. Method for processing an IP telephony request (RQ), called a request to be processed, belonging to an IP telephony session, called current session, by a processing server (SBE), called an assigned server, belonging to a group (GP) of servers, characterized in that the method comprises the following steps: • Reception of the request to be processed (RQ) transmitted by a management entity (100) in charge of assigning the requests to be processed for the current session; • Reading in a database (SDB), called a session base, of information (INF) relating to the current session; • Processing of the request to be processed (RQ) using the information (INF) read.

9. Processing method according to claim 8 characterized in that the request to be processed (RQ) includes a field which takes a value (V), 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 in that the information (INF) read in the session base (SDB) is accessible thanks to the key value (V).

10. Processing method according to claim 8 characterized in that the number of processing servers belonging to the group (GP) of servers varies over time.

11. Processing method according to claim 9 characterized in that the method further comprises a step of recording in the session database (SDB) information (INF) relating to the processing by the assigned server (SBE) of the request to be processed (RQ), said information (INF) being accessible using the key value (V).

12. Management entity (100) capable of carrying out a method for managing the allocation to a processing server (SBE), belonging to a group (GP) of servers, of IP telephony requests (RQ), called requests to be processed, belonging to the same IP telephony session, called current session, characterized in that the management entity (100) comprises: • A module (101) for receiving a request to be processed (RQ); • A module (102) for selecting a processing server (SBE) in the group (GP) of servers; • A module (103) for transmitting a request to be processed (RQ); and in that, during the current session, a reception by the reception module (101) of a request to be processed (RQ) triggers a selection by the selection module (102) of a processing server (SBE) in the group (GP) of servers, and in that the request to be processed is transmitted by the transmission module (103) to the selected server (SBE), called the assigned server, for processing.

13. Server (SBE) for processing an IP telephony request (RQ), called a request to be processed, belonging to an IP telephony session, called a current session, said processing server (SBE) belonging to a group (GP) of servers, characterized in that the server (SBE) comprises the following modules: • A module (201) for receiving the request to be processed (RQ) transmitted by a management entity (100) in charge of allocating the requests to be processed for the current session; • A module (202) for reading in a database (SDB), called a session database, information (INF) relating to the current session; • A module (203) for processing the request to be processed (RQ) using the information (INF) read.

14. A computer program capable of being implemented by a management entity (100), the program comprising code instructions which, when executed by a processor, performs the steps of the management method according to claim 1.

15. Computer program capable of being implemented by a processing server (SBE) of an IP telephony request (RQ), the program comprising code instructions which, when executed by a processor, performs the steps of the processing method according to claim 9.

Images