EP2119190B1 - Service continuity management in a network - Google Patents

Description

The present invention relates to a service over IP (for 'Internet Protocol'), in particular to IP telephony called "Voice over IP" (for "Voice over IP" in English).

IP telephony advantageously allows, on the one hand, a reduction in the cost of telephone calls compared to traditional telephony, and on the other hand, the coupling of telephony with the functions and services of IT and IP networks. .

However, a telephony service is a real-time service that requires a relatively high level of availability, robustness and resilience. In the context of conventional telephony (PSTN for 'Switched Telephone Network'), based on circuit switching, this level of robustness and availability is obtained by the implementation of methods that are not applicable to IP telephony, which is not based on circuit switching.

An IP network offering a telephony service conventionally comprises a service platform, as well as equipment for accessing the service, or POP (for 'Point Of Presence'), which are in charge of managing access to the terminals. customer users to the service in question.

Conventionally, these POPs are associated with edge management session equipment (Border Session Controller or BSC, or Session Border Controller or SBC), whose main functions have been identified in the document 'Requirements from Session Initiation Protocol Session Border Control Deployments', by Camarillo et al., Draft-ietf-sipping-sbc-funcs, November 2006 . These SBCs are located between the client terminals and the IP telephony service platforms. An SBC is usually located in an IP access POP (although this is not a necessary condition for the operation of the telephony service) and represents, for a given client terminal, a single point of entry to the service. of telephony. Such management of access to a service makes it possible to hide, at the client terminals, the service platform and, more generally, the network architecture implemented by an operator. It is then possible to guarantee a service seal.

SBCs are a point of passage for both signaling flows to establish communication and for media flows that flow between client terminals. The signaling flows may be aimed at establishing a call, for example on the basis of protocols such as SIP (for Session Initiation Protocol), or H.323, as defined by the ITU-T (for International Telecommunication Union Telecommunication Standardization Section), or IAX (for 'Inter-Asterisk eXchange Version 2') as defined in the draft-guy-iax-02 document, Work In Progress, October 2006 by Spencer, Shumard, Capouch and Guy . The media streams, for their part, can be exchanged between client terminals according to protocols of RTP type (for Real-Time Transport Protocol in English) or type IAX for example.

An SBC then receives, on the one hand, signaling messages from the service platform, or respectively from the client terminals. Then, after processing these messages, the SBC relays them to the end client terminals, or respectively to the service platform.

Then, when a media stream is exchanged from a first client terminal to a second client terminal used by a client of the service, which are respectively associated with a first and a second SBC, this media stream is received at the first SBC, and then relayed to the second SBC, the latter then being in charge of transmitting this media flow to the second client terminal. By doing so, the client terminals can not communicate directly with each other, the service seal being thus guaranteed.

It can also be noted that the SBCs can also perform other functions such as a filter function or an address translation function for offers based on the IPv4 protocol (version 4).

When an SBC can no longer communicate with the platform, the service offered to the client terminal clients it manages is cut off. In order to increase the fault resistance in such a network, and to efficiently and robustly transport the signaling messages allowing the establishment of the communications as well as the transport of the media flows between the client terminals, it is possible to set up a redundancy of the elements of the service platform in the form of backup elements (or 'backup' in English), so that we can substitute a spare element to a defective element of the service platform. Such an architecture requires that such a backup element has a configuration and behavior identical to the defective element to which it must replace.

However, the provision of such backup equipment for the service platform has many disadvantages. First of all, the duplication of these elements is costly both in terms of the infrastructure to be implemented and at the level of redundancy management itself.

In addition, such redundancy does not make it possible to mitigate, in all circumstances, the consequences of a breakdown relating to the links between the service platform and the SBCs.

The document US 6,973,027 describes communication management of a terminal in a network. The terminal is connected to a proxy which itself is connected to a gatekeeper (or 'gatekeeper' in English) which can be considered as a service platform.

The present invention improves the situation.

A first aspect of the present invention provides a method of managing a service offered to a user of a terminal in a network comprising a service platform and equipment including edge session controllers, each of the border session controllers. being adapted to communicate with the service platform. At least one edge session controller is adapted to route messages received from the terminal to the service platform.

1. /a/ décider que la plateforme de service n'est pas accessible sur la base d'un contrôle d'accessibilité ; et
2. /b/ opérer dans un mode de fonctionnement autonome dans lequel le contrôleur de session en bordure donné sélectionne un équipement du réseau distinct de la plateforme de service et route au moins un message reçu depuis le terminal vers ledit équipement du réseau sélectionné.

The method includes the following steps at the edge session controller:

1. / a / decide that the service platform is not accessible on the basis of an accessibility check; and
2. / b / operating in an autonomous operating mode in which the given edge session controller selects a device of the network separate from the service platform and route at least one message received from the terminal to said equipment of the selected network.

By doing so, it is possible to guarantee continuity of service offered to the user of the terminal, even in the case where the edge session controller, which is in charge of managing the terminal in question, has lost access to the service platform. In this case, instead of automatically routing the messages received from the terminal to the service platform, it selects another device of the network to continue to provide the service to the user of this terminal.

The selected network equipment may advantageously be an edge session controller having access to the service platform. Thus, in this case, the message routed to said selected network equipment is transmitted from the selected network equipment to the service platform.

The selected network equipment can then act as a proxy edge session controller and thereby relay the messages that are normally transmitted from the given edge controller to the service platform.

• /b-1/ émettre une requête de mandataire à destination d'au moins un autre contrôleur de session en bordure du réseau ;
• /b-2/ si au moins une réponse à ladite requête de mandataire est reçue, sélectionner, en tant que mandataire, un contrôleur de session en bordure parmi les contrôleurs de session en bordure ayant émis une réponse.

In one embodiment of the present invention, each edge session controller implements the accessibility check on the platform, and in step / b /, the following steps are performed:

• / b-1 / issuing a proxy request to at least one other session controller at the edge of the network;
• / b-2 / if at least one response to said proxy request is received, selecting, as proxy, an edge session controller from the edge session controllers that have issued a response.

Thus, to select an edge session controller as a proxy, the given edge session controller queries all or part of the other edge controllers at the edge of the network. The term 'network' is understood to mean not only the network layer, that is to say the layer 3, of the OSI model (for 'Open System Interconnection'), but also any interconnection between different devices.

These edge session controllers respond if the service platform appears to them as accessible based on the accessibility control they implement. Then, the edge session controller may then select a proxy from the edge session controllers that responded, i.e. from the edge session controllers that were polled and that have access to the platform. service.

In one embodiment of the present invention, in step / b /, the edge session controller receives a message from the terminal to a destination terminal, and the selected network equipment is a session controller. border responsible for managing said destination terminal. Messages routed to the selected network equipment are then transmitted from the selected network equipment to the destination terminal.

In this context, a message received from the terminal by the given session controller passes through another edge session controller that is the one selected, and then is routed to the destination terminal without going through the service platform. Such an embodiment may especially be advantageous in the case where the other session controllers at the edge of the network also do not have access to the service platform.

• /b-i/ émettre un message de requête de destinataire à destination d'au moins un autre contrôleur de session en bordure ;
• /b-ii/ si une réponse à la requête de destinataire est reçue, sélectionner le contrôleur de session en bordure ayant émis ladite réponse ;

un contrôleur de session en bordure décidant d'émettre une réponse à la requête de destinataire en fonction de la base de données locale.In this case, each edge session controller maintains a local database indicating terminals that said edge session controller handles, and step / b / is performed according to the following steps, at the edge session controller. given:

• / bi / transmitting a recipient request message to at least one other edge session controller;
• / b-ii / if a response to the recipient request is received, select the edge session controller that has issued said response;

an edge session controller deciding to issue a response to the recipient request based on the local database.

Thus, as each edge session controller locally knows the terminals it is responsible for managing, according to the indications stored in its local database, a message received from the terminal may not pass through the platform of service.

In a variant, it is planned to combine the autonomous modes of operation above.

For this purpose, it can be provided that, if at least one edge session controller has access to the service platform, the selected network equipment is an edge session controller having access to the service platform, the routed message. to said selected network equipment being transmitted from the selected network equipment to the service platform; and if not, the selected network equipment is a device in charge of managing the destination terminal, the message routed to said selected network equipment being transmitted from the selected network equipment to the destination terminal.

This alternative is advantageous because it makes it possible to privilege the autonomous mode of operation, by proxy, in which the service remains rendered by the service platform and is therefore identical to that provided during normal operation of the session controller. the edge.

Such equipment in charge of managing the destination terminal may be an edge session controller.

This equipment can also be a service gateway connecting the network to another network. In this case, the given edge session controller may have information relating to this service gateway. In step / b /, when the edge session controller receives a message from the terminal to a destination terminal, said selected network equipment is the service gateway when the destination terminal is managed by said other network.

Thus, it can even ensure continuity of service for a user of a terminal that seeks to communicate with a destination terminal managed in a network different from that by which the terminal in question is managed.

Here, the term 'network' can refer to a service domain, the latter being able to correspond in particular to a telephony offer. Thus, the gateway then makes it possible to link two different service domains that can correspond to two different service offers respectively.

• recevoir une requête de mandataire ;
• si la plateforme est détectée comme accessible, émettre une réponse à la requête de mandataire.

The management method according to one embodiment of the present invention may, in addition, provide for the implementation of the following steps:

• receive an agent request;
• if the platform is detected as accessible, issue a response to the proxy request.

Thus the edge session controller can also be a proxy controller.

• recevoir une requête de destinataire indiquant un terminal destinataire ;
• déterminer si ledit contrôleur de session est en charge de gérer le terminal destinataire en fonction d'informations stockées dans la base de données local ;
• et dans l'affirmative, émettre une réponse à la requête de destinataire ;

le contrôleur de session en bordure étant adapté pour transmettre, à destination du terminal destinataire, des messages reçus depuis un autre contrôleur de session en bordure.The method may also include the following steps:

• receive a recipient request indicating a destination terminal;
• determining whether said session controller is responsible for managing the destination terminal based on information stored in the local database;
• and if so, issue a response to the recipient request;

the edge session controller being adapted to transmit, to the destination terminal, messages received from another edge session controller.

Here, it can be provided that the recipient request indicates the destination terminal by a corresponding telephony identifier.

Thus the edge session controller can also play a role of recipient controller.

1. /1/ émettre un message de contrôle à destination de la plateforme de service et déclencher un temporisateur ;
2. /2/ contrôler si une réponse au message de contrôle est reçue depuis la plateforme de service avant expiration dudit temporisateur ;
3. /3/ répéter les étapes /1/ et /2/ N fois, N étant un nombre entier prédéterminé;
4. /4/ si aucune réponse n'est reçue avant expiration du temporisateur pour les N fois, décider que la plateforme de service n'est pas accessible.

It can be planned to implement an accessibility control according to the following steps:

1. / 1 / issue a control message to the service platform and trigger a timer;
2. / 2 / checking whether a response to the control message is received from the service platform before said timer expires;
3. / 3 / repeating the steps / 1 / and / 2 / N times, N being a predetermined integer;
4. / 4 / if no response is received before the timer expires for N times, decide that the service platform is not accessible.

A second aspect of the present invention provides an edge session controller adapted to implement a management method according to the first aspect of the present invention.

• une unité de contrôle adaptée pour décider que la plateforme de service n'est pas accessible sur la base d'un contrôle d'accessibilité ; et
• une unité de gestion de mode de fonctionnement adaptée pour basculer dans un mode de fonctionnement autonome, en fonction d'une décision prise par l'unité de contrôle, dans lequel le contrôleur de session en bordure sélectionne un équipement du réseau distinct de la plateforme et route au moins un message reçu depuis le terminal vers ledit équipement du réseau sélectionné.

This edge session controller may be adapted to transmit messages received from the terminal to the service platform and may include:

• a control unit adapted to decide that the service platform is not accessible on the basis of an accessibility check; and
• an operating mode management unit adapted to switch to a stand-alone operating mode, according to a decision made by the control unit, wherein the edge session controller selects a separate network equipment from the platform and route at least one message received from the terminal to said equipment of the selected network.

A third aspect of the present invention provides a service platform in a network providing a service to a user of a terminal, said network further comprising edge session controllers, each adapted to communicate with the service platform,
said service platform being adapted to respond to an accessibility control message received from a border session controller.

• recevoir une requête de destinataire indiquant un terminal destinataire ; et
• répondre à ladite requête de destinataire si le terminal destinataire est géré dans ledit second réseau.

A fourth aspect of the present invention provides a service gateway in a first network providing a service to a user of a terminal and in a second network, said first network further comprising edge session controllers, each being adapted to communicate. with the service platform, said service gateway being adapted for;

• receive a recipient request indicating a destination terminal; and
• responding to said recipient request if the destination terminal is managed in said second network.

A fifth aspect of the present invention provides a computer program for installation in a session controller according to the second aspect of the present invention, including instructions for carrying out the method according to the first aspect of the present invention. invention, during a program execution by means of processing the session controller.

A sixth aspect of the present invention provides a computer readable recording medium on which is recorded the computer program according to the fifth aspect.

A seventh aspect of the present invention proposes a computer program intended to be installed in a service platform according to the third aspect of the present invention, comprising instructions able to implement the method according to the first aspect, during a execution of the program by means of processing the service platform.

An eighth aspect of the present invention provides a computer readable recording medium on which the computer program according to the seventh aspect is recorded.

• la figure 1 illustre un réseau composé par des éléments de service de téléphonie IP selon un mode de réalisation de la présente invention ;
• la figure 2 illustre une gestion d'une inaccessibilité de la plateforme de service depuis un contrôleur de session en bordure selon un mode de réalisation de la présente invention ;
• la figure 3 illustre une gestion d'un basculement entre différents modes de fonctionnement d'un contrôleur de session en bordure selon un mode de réalisation de la présente invention ;
• la figure 4 illustre une gestion d'initiation d'appel dans un mode de fonctionnement autonome dit 'local'.

The invention will also be better understood with the aid of the drawings, in which:

• the figure 1 illustrates a network composed by IP telephony service elements according to an embodiment of the present invention;
• the figure 2 illustrates management of inaccessibility of the service platform from an edge session controller according to an embodiment of the present invention;
• the figure 3 illustrates management of a switchover between different modes of operation of an edge session controller according to an embodiment of the present invention;
• the figure 4 illustrates a call initiation management in an autonomous operating mode called 'local'.

In order to guarantee continuity of service even when the exchanges between an SBC and the service platform are no longer possible, whatever the origin of the problem affecting these exchanges, it is foreseen that an SBC can operate either in a normal operating mode, which corresponds to the case where the service platform is accessible for him and in which the messages between two terminals transit via the service platform, either in an autonomous mode of operation, which corresponds to the case where the service platform is not accessible to him.

In the case where the service platform is accessible from this SBC, the messages received from the client terminals are relayed to the service platform which, in turn, is responsible for implementing the telephone routing of these messages.

The term 'autonomous mode of operation' is understood to mean a mode of operation of the SBC in which the routing of messages received from its client terminals is implemented at the level of the SBC itself and not at the level of the service platform. .

Switching from a normal mode of operation to a stand-alone mode of operation is performed according to the accessibility status of the platform for the SBC considered. For this purpose, it is expected that an SBC has means of controlling its state of accessibility to the platform.

When the access of this SBC to the service platform is detected as faulty, the SBC then switches to a stand-alone mode of operation. Then, when the service platform is again detected as accessible, the SBC can return to a normal operating mode.

An SBC can control the accessibility status of the service platform by issuing a "keepalive" type control message. Such a message can be transmitted at a determined frequency. No limitation is attached to the method of sending these control messages, nor to the frequency with which they are sent.

The SBC preferably then manages a timer linked to waiting for a response from this service platform.

When the SBC is in normal operating mode, the timer can be triggered upon transmission of a control message. Then, when the timer expires before a response is received from the service platform, the SBC may decide to switch to the stand-alone mode of operation.

It can also be provided that the switchover in the autonomous operating mode is triggered only when an integer N of control messages are successively sent to the service platform without the latter responding before the expiration of the associated timer. This number N can then be determined according to the frequency with which the successive control messages are sent.

A service platform of this type comprises different functional elements. Such a control message can be received by these different functional elements of the service platform, and all or part of these functional elements are then capable of responding to the control messages of the SBC.

The accessibility status of these elements can be determined for example on the basis of SNMP (Simple Network Management Protocol) type traces or on the basis of alarms and notifications resulting from the functional elements of the service platform. The method implemented to determine the accessibility status of the service platform is not described in detail here, and no limitation is attached thereto.

When the SBC is in stand-alone operation mode, it may be advantageous to implement an accessibility detection method to the service platform as well, in order to be able to handle the switchover in the normal operating mode in the case the platform would be detected again as accessible.

For this purpose, the same method of accessibility detection can be implemented both in the case where the SBC is in normal operating mode and in the case where the SBC is in autonomous operating mode.

Thus, in the case where the SBC operates in autonomous operation mode, a timer can be triggered upon transmission of a control message. Then, when a response is received from the service platform before the timer expires, the SBC may decide to switch to the normal operating mode.

In the same way as for detecting the loss of access to the platform as described above, recovery can be considered effective only after one or more replies to the control messages sent successively, each being received before the expiration of the associated timer. When access to the service platform is restored, the SBC then switches to the normal operating mode.

However, in order to guarantee a certain level of quality for the service offered, it is necessary to ensure that this changeover to the normal operating mode is smooth and seamless.

It may therefore be advantageous for the SBC to continue to handle sessions that have been established in the SBC standalone mode of operation and that are still in progress at the time the SBC switches to the normal operating mode, until these sessions are completed.

Accessibility control is performed at the level of the SBC considered and does not mean that the service platform itself is no longer operational, even if this may be the cause of a loss of access to the platform. service for this SBC.

The autonomous mode of operation of an SBC implies that the latter no longer automatically routes, as in the normal operating mode, messages received from a client terminal to the service platform. The routing of these messages is then managed at the level of the SBC which operates in autonomous mode.

In an autonomous mode, it can be expected that the SBC considered seeks to still transmit the messages received from a client terminal to the service platform through another SBC network which, he has access to the service platform. Indeed, it is possible that the service platform is detected as inaccessible only by one or a part of the SBC network, and for others, it remains accessible. This may be the case when the detected inaccessibility states are based on localized network connection problems.

Under these conditions, it can be expected that the SBC seeks to elect a proxy SBC among those who have access to the service platform, through which he could then access this service platform.

Thus, an embodiment of the present invention provides a collaborative mode of operation. For this purpose, it is expected that the SBCs can communicate with each other on the basis of a protocol, which may be a dedicated protocol, particularly by point-to-multipoint or 'anycast' exchanges, ie say when several SBCs have the same address, the SBC closest to the source sending traffic to this address receiving this traffic.

No limitation is attached to the present invention with regard to the inter-SBC communication mode used.

Subsequently, by way of example, the present invention is described in its application to an inter-SBC protocol based on a general broadcast mode, or in English "multicast". Thus, the SBC inter exchanges are then carried out on the basis of multi-recipient groups, a group potentially containing all the SBCs of the network in question. Under these conditions, a message sent to this group is then received by all SBCs.

For example, it can be provided that, at startup, all the SBCs of the network, which may be a telephone network, belongs to a given multicast group G identified by a specific IP address.

Then, upon detection of the inaccessibility of the service platform for an SBC, the latter sends a proxy request, a message of the SBC_PROXY type, to the specific IP address of the multicast group G, in order to determine if at least a group SBC manages to join the service platform.

Upon receipt of this proxy lookup message, the SBCs of this group inform the sending SBC of this message about their accessibility status to the service platform.

No limitation is attached to the present invention with regard to the mechanism implemented to transmit information relating to a state of accessibility of the service platform from one SBC to another SBC.

It can be provided for this purpose that an SBC responds to this proxy search message only if it has access to the service platform and that, therefore, the absence of a response means that this access is impossible. Under these conditions, the SBC transmitting the request message can arm a timer. Then, when the timer expires before a response is received, the sending SBC concludes that none of the recipient SBCs can be a proxy SBC.

When a Group G SBC has detected the service platform as accessible, it then transmits a response to the sending SBC. This response can be sent in unicast mode by a message of type 'ACKNOWLEDGE'.

In the case where one or more replies have been received, the issuing SBC may have a proxy SBC. If several SBCs of group G have responded, it can even select one based on selection criteria, no limitation being attached to the present invention with regard to such selection criteria.

A proxy SBC is responsible for relaying the messages that pass through the SBC transmitter to the service platform, the latter can then treat these messages as if they were received from the SBC issuer.

In the case where, at the expiry of the timer, no response has been received, or in the case where a determined number N of proxy search messages, sent successively, have remained unanswered, the SBC can not then not have a mandatory SBC.

In one embodiment, the service platform can also be notified of this configuration, in particular for service coherency or security purposes. Nevertheless, this notification is optional.

In such a case, it can advantageously be expected that the transmitting SBC then switches to a local operating mode in which it replaces the service platform for at least part of the functions that the latter provides for the client terminals that are attached to the SBC considered.

For this purpose, in order to allow an SBC to implement at least some functionalities of the service platform, that is to say so that an SBC has the capacity to operate in a local operating mode the client terminals whose access is managed by the POP to which it is attached, this SBC may have a database in which at least a portion of the registration data relating to these client terminals is also stored.

A client terminal performs a recording phase during which it sends to the network, that is to say to the SBC which is responsible for its management, a recording message containing recording data. which allow the network to provide the service in question. In a normal operating mode, this message is received at the level of the SBC attached to the POP managing the access to the service, which may be a telephony service, of the user of the client terminal. This SBC relays this message to the service platform that maintains a database storing this registration data.

Thus, since such a registration message passes through the SBC, because of its function in the architecture of the considered network, the local database can advantageously be updated easily.

Under such conditions, on the basis of the data thus stored, the SBC can substitute itself at least in part for the service platform for the client terminals for which it is responsible, since it has registration data which enables it in particular to to contact these client terminals. The SBC can then notably respond to call setup requests to the client terminals for which it is responsible.

In addition, this registration information is up to date, since it is extracted at the level of exchanges that are conventionally performed between the service platform and the client terminals.

It should be noted that when the last client terminal registration took place before switching to local operating mode, it is not easy to ensure that the registration data stored in the service platform database is up-to-date data when it is available again for the SBC.

In addition, client terminals that registered during the time the SBC operates in local operating mode are not known to the service platform.

Therefore, when the service platform is again detected as being accessible from the relevant SBC, the latter re-transmits to the service platform all the registration requests for all the client terminals that are managed in the server. local mode of operation.

Such an embodiment makes it possible to guarantee that the service platform has up-to-date registration data for the client terminals that have issued such registration requests.

Then, any session or communication that is initiated after the switchover to the local operating mode is processed in a conventional manner, and thus the service platform database is updated correctly thereafter.

An autonomous mode of operation can therefore correspond to either the collaborative mode of operation or to the local mode of operation.

It can also be expected that, when the SBC switches from a normal mode of operation to a stand-alone mode of operation, it first attempts to switch to a collaborative mode of operation in which it accesses the service platform via a proxy SBC then, in the case where this mode of collaborative operation is not possible, the SBC then switches to the local operating mode. This may be particularly the case when the service platform is not operational or when the SBC considered can not exchange information with the other SBCs of the network.

It is then preferable that all or part of the SBCs maintain respective local databases to anticipate a possible switchover to a local operating mode.

In a variant, provision can be made for the SBC to switch to the local operating mode as soon as a loss of accessibility to the platform is detected, without seeking to select a proxy SBC.

It can also be expected that the SBC can only switch to a collaborative mode of operation, and in this case, the management of a local database to the SBC is not required.

The figure 1 illustrates a network according to an embodiment of the present invention. This network 10 comprises four SBCs, SBC1, SBC2, SBC3 and SBC4, which are adapted to communicate with a service platform Serv 11. The SBC 1 is responsible for managing the client terminals T1 to T3, the SBC 2 the client terminals T4 at T6, the SBC 3 the T7 to T9 client terminals, and the SBC 4 the T10 and T11 client terminals.

SBC1 detects that the service platform is not accessible. It seeks to switch to the autonomous mode of operation which is primarily the collaborative mode of operation. For this purpose, it sends a proxy request SBC_PROXY in broadcast mode to the group of SBCs including SBC2, SBC3 and SBC4.

These SBC2, SBC3, and SBC4 respond to this SBC_PROXY message by sending messages of type 'ACKNOWLEDGE' to SBC1 so as to inform him that, from their point of view, the service platform is accessible and operational.

SBC1 can then choose from the group of SBC2, SBC3 and SBC4 an SBC as SBC Proxy (or proxy). If SBC3 is selected as the SBC1 proxy SBC, all signaling messages received by SBC1 are transmitted to SBC3, which in turn transmits them to service platform 11.

If no SBC responds to the SBC_PROXY message, the SBC1 then operates in local operating mode.

In the local operating mode, upon receipt of a call setup request, such as an 'INVITE' message according to the SIP protocol (for 'Session Initiation Protocol'), the SBC attempts to terminate the call. without using the service platform.

For this purpose, it sends a destination request to all or part of the SBCs of the network in order to determine which SBC is in charge of the client terminal receiving the signaling message received. Any limitation is attached to the protocol used to issue such a recipient request.

In a first case, the client terminal receiving the call initiation message is managed by the SBC which has received the call initialization request and which therefore operates in the local operating mode. In this case, the processing of the request is performed at this SBC, which therefore provides call routing functions here.

For this purpose, this SBC can verify that data relating to this recipient client are stored in its local database, either before sending the recipient request, or in parallel to the sending of this request to the SBC.

It is also possible for the SBC to send a recipient request to the SBC group to which it belongs, and thereby receive this request and process it like the other SBCs, responding favorably in the case where the client terminal recipient is the responsibility of this SBC.

In a second case, a SBC other than the one receiving the call establishment request, manages the client terminal receiving this request, this other SBC, upon receipt of the recipient request, checks whether it is in charge of the request. destination client terminal based on the data stored in its local database. If this is not the case, this SBC preferably emits no negative answer, the absence of response translating this information.

In the case where this other SBC is responsible for this destination client terminal, the latter then responds to the SBC sending the recipient request. In particular, it must provide information that enables the transmitting SBC to transmit to it the call initiation request received from its client terminal.

This other SBC then behaves like a node of the service platform dedicated to call routing.

On receipt of the response to its recipient request, the SBC then transmits the received call initiation request to the recipient SBC. Then, the Call processing can be managed on the basis that messages exchanged between the terminals pass between the two SBCs.

In a third case, the destination client terminal is not known to any of the SBCs that have received the request from the recipient SBC. This may be the case when the destination client terminal belongs to another IP domain. In this case, the call initiation request message can then be routed to a signaling gateway for accessing a remote service.

It can then be provided that the information relating to such a signaling gateway is configured at each SBC. For this purpose, it is possible to use FQDN addresses (for 'Fully Qualified Domain Name' in English) to have great flexibility. When the sending SBC has received no positive response to its destination SBC request and / or the recipient client terminal is not present in its database, the latter can then transmit the call initiation request to the signaling gateway to relay this message to the appropriate external service for processing.

It can also be provided that the signaling gateway is part of the multicast group G identified by the specific IP address. The gateway is then in charge of responding positively to any recipient request it receives, and which concerns a domain for which it ensures interworking.

It should be noted that, in the case where the signaling gateway is part of multicast group G, it is preferable that it does not respond to proxy requests. However, it can be adapted to issue such messages if it loses access to the service platform.

In the case where the service platform is no longer operational, all the SBCs detect a loss of accessibility to it.

The figure 2 illustrates management of inaccessibility of the service platform from an edge session controller according to an embodiment of the present invention.

The network 10 is similar to that illustrated in figure 1 .

The SBC1 has switched to local operating mode, either directly after detecting loss of the service platform, or even after sending one or more unanswered proxy requests.

On receipt of a call initiation message 21 sent by the client terminal T1 to the client terminal T7, the SBC1 verifies that the client terminal T7 is not present in its database, and sends a request for address to the multicast group G, to determine with which SBC the client terminal T7 is managed. SBC3 responds positively to this request, indicating its own contact information. The SBC1 transmits the call initialization message 22 to the client terminal T7. The SBC3 processes this request and relays it to the client terminal T7 via a message 23. The destination client terminal T7 then responds to the SBC3 with a message 24 of the '200 OK' type according to the SIP protocol if the call establishment is managed according to this protocol. The SBC 3 then transmits the message 25 to the SBC1, the latter processing this response and relaying it to the client terminal T1 in the form of a message 26.

Then, as in a conventional case, the exchanges can then be implemented according to a protocol of the RTP type between the client terminals T1 and T7, the latter having no knowledge of the loss of access to the service platform.

The figure 3 illustrates management of failover between different modes of operation according to one embodiment of the present invention.

The considered SBC operates in normal operation mode at a step 301. Then, on the basis of a mechanism as described above, this SBC regularly checks its accessibility status of the service platform at a step 302. the platform is detected as accessible, the SBC remains in the normal operating mode 301.

If the service platform is detected as not accessible, the SBC switches to collaborative operation mode in step 303. Then, the SBC sends a proxy request 304 to the different SBCs of the broadcast group considered by managing an associated timer as described herein. -before.

When the timer expires, the SBC checks which SBCs of that group responded at a step 306.

If no response from the other SBCs is received when the timer expires, the SBC switches to local operating mode at a step 310.

On the other hand, if in step 306 a response is received to the proxy lookup message, the sender SBC selects, at a step 307, a proxy SBC (denoted SBC Proxy in the figure) from the SBCs that responded.

Then, at a step 308, the processing of the required call is made via the selected proxy SBC, that is to say that the messages received from a client terminal of the sender SBC are transmitted to the service platform by the intermediary of the SBC agent.

When at a step 309, the service platform is again detected as accessible from an SBC which operates either in the collaborative operating mode or in the local operating mode, it is expected that this SBC then switches to the mode of operation. normal operation, from step 301.

It can be planned to implement the control of the accessibility of the service platform from a SBC regularly, or even at a determined frequency.

The figure 4 illustrates call setup management in a local mode of operation according to an embodiment of the present invention.

At a step 411, a call initiation message is received on an SBC of the network operating in the local operating mode. In this mode of operation, the SBC maintains its local database.

On receipt of a call setup request from a client terminal of this SBC to a destination client terminal, the SBC can check in its local database, if it is in charge of the destination client terminal to Step 412. If this is the case, the processing of this call can be done locally at this SBC. On the other hand, if it is not, the SBC sends a destination SBC request to the SBC group at a step 413.

Alternatively, the SBC can query the remote SBCs directly before checking the data in its local database, for example. sending a recipient SBC request to the concerned SBC group, and thereby this SBC can proceed directly from step 411 to step 413.

Then, the SBC may receive a response to this recipient SBC request from at least one SBC of the group at a step 416. In this case, the call initiation message is transmitted to the recipient SBC that has responded , for processing the call setup request at a step 416 if the responding SBC is the sending SBC itself, at step 418 if it is a separate SBC.

It can be expected that, in the case where no SBC of the destination SBC request broadcast group SBC responds, at a step 414, the sending SBC transmits this request to a service gateway. If the latter responds to the destination SBC request, the call establishment request is transmitted to this service gateway for processing at a step 415. As described above, the gateway may also be part of the elements of the network requested to step 413. A positive response from him (at step 416) will similarly lead to the transmission of the call setup request to that service gateway for processing at a step 415.

Claims (11)

1. A method of managing a service offered to a user of a terminal in a network (10) comprising a service platform (11) and equipment including session border controllers (SBC1, SBC2, SBC3, SBC4) that each are adapted to communicate with the service platform (11),
   at least one given session border controller being adapted to route messages received from the terminal, to the service platform,
   said method comprising the following steps at the level of the given session border controller:

   /a/ deciding that the service platform is not accessible on the basis of an accessibility check; and

   /b/ operating in an autonomous operating mode in which the given session border controller selects an equipment of the network separate from the service platform and routes at least one message received from the terminal to said selected network equipment, in which:

   - if at least one session border controller has access to the service platform, said selected network equipment is a session border controller having access to the service platform, the message routed to said selected network equipment being transmitted from the selected network equipment to the service platform; and,

   - otherwise, the selected network equipment is an equipment in charge of managing the destination terminal of said message, the message routed to said selected network equipment being transmitted from the selected network equipment to said destination terminal.
2. A method of managing a service according to claim 1, in which each session border controller implements the platform accessibility check and,
   in which in step /b/, the following steps are carried out:

   /b-1/ transmitting a proxy request to at least one other session border controller of the network;

   /b-2/ if at least one response to said proxy request is received, selecting, as a proxy, a session border controller from the session border controllers having sent a response.
3. A method of managing a service according to claim 1, in which, in step /b/, the session border controller receives a message from the terminal intended for a destination terminal, and
   said selected network equipment is a session border controller in charge of managing said destination terminal;
   the message routed to said selected network equipment being transmitted from the selected network equipment to the destination terminal.
4. A method of managing a service according to claim 3, in which each session border controller maintains a local database indicating terminals that said session border controller manages, and
   in which step /b/ is carried out according to the following steps, at the level of the given session border controller:

   /b-i/ transmitting a destination request message to at least one other session border controller;

   /b-ii/ if a response to the destination request is received, selecting the session border controller having sent said response;

   a session border controller deciding to transmit a response to the destination request according to the local database.
5. A method of managing a service according to claim 1, in which, in step /b/, the session border controller receives a message from the terminal intended for a destination terminal, and
   said selected network equipment is a service gateway connecting said first network to a second network in charge of managing said destination terminal;
   the message routed to said selected network equipment being transmitted from the selected network equipment to the destination terminal.
6. A management method according to any of the preceding claims, comprising moreover, at the level of the given session border controller, the following steps:

   - receiving a proxy request;

   - if the platform is detected as accessible, transmitting a response to the proxy request.
7. A management method according to any of the preceding claims, comprising moreover, at the level of the session border controller, the following steps:

   - receiving a destination request indicating a destination terminal;

   - determining if said session controller is in charge of managing the destination terminal according to information stored in the local database;

   - and, in the affirmative, transmitting a response to the destination request;

   the session border controller being adapted for transmitting, to the destination terminal, messages received from another session border controller.
8. A method of managing a service according to any of the preceding claims, in which the platform accessibility check is implemented according to the following steps, at the level of the session border controller:

   /1/ transmitting a check message to the service platform and starting a timer;

   /2/ checking if a response to the check message is received from the service platform before said timer elapses;

   /3/ repeating steps /1/ and /2/ N times, N being a predetermined integer;

   /4/ if no response is received before the timer elapses for the N times, deciding that the service platform is not accessible.
9. A session border controller in a network offering a service to a user of a terminal, said network (10) comprising a service platform (11) and other session border controllers (SBC1, SBC2, SBC3, SBC4),
   each session border controller being adapted for communicating with the service platform (11),
   said session border controller being adapted for transmitting messages received from the terminal to the service platform and comprising:

   - a control unit adapted to decide that the service platform is not accessible on the basis of an accessibility check; and

   - an operating mode management unit adapted for switching into an autonomous operating mode, according to a decision taken by the control unit, in which the session border controller selects an equipment of the network separate from the platform and routes at least one message received from the terminal to said selected equipment of the network, in which:

   - if at least one session border controller has access to the service platform, said selected network equipment is a session border controller having access to the service platform, the message routed to said selected network equipment being transmitted from the selected network equipment to the service platform; and

   - otherwise, the selected network equipment in an equipment in charge of managing the destination terminal, the message routed to said selected network equipment being transmitted from the selected network equipment to a destination terminal.
10. A computer program comprising program code instructions for the implementation of the method according to claim 1.
11. A storage medium, which can be read by a computer, on which the computer program according to claim 10 is stored.

Images