METHOD OF PROVIDING BACKUP FOR AN OPENSCAPEVOICE REGISTER CONFIGURATION

A method of providing backup for an OpenScapeVoice (OSV) register configuration, with at least one OpenScapeBranch (OSB), the at least one OSB providing communications to Session Initiation Protocol (SIP) subscribers, and communicating on a main routing path, via a main Session Boarder Controller (SBC) configuration with an OSV server based on SIP, the OSB maintaining a database in which SIP subscribers currently communicating are registered. The method can include:          copying the database to a redundancy SBC configuration on the basis of the SIP protocol,     establishing an alternative routing path for communication of the OSB via the redundancy SBC to the OSV server,     continuing the providing of the communications of the SIP subscribers via the redundancy SBC configuration.       The method can be utilized in a system for providing backup for an OSV register configuration, a non-transitory computer readable medium, and a terminal device.

FIELD

The present invention concerns OpenScapeVoice (OSV) register configurations with redundancy (i.e., a main or primary network path, and an alternative path) for the Session Border Controller (SBC) connecting to OpenScapeBranches (OSB) at branch offices via different WAN providers. The SBCs are typically located at different enterprise network sub-domains.

BACKGROUND

In more detail, the present invention relates to a method of providing backup for an OpenScapeVoice (OSV) register, with at least one OpenScapeBranch (OSB), the at least one OSB providing communications to Session Initiation Protocol (SIP) subscribers, and communicating on a main routing path, via a main Session Boarder Controller (SBC) configuration (SBC1, SBC2) with an OSV server on the basis of SIP protocol, the OSB maintaining a database in which SIP subscribers currently communicating are registered. The OSV registers an SBC configuration (SBC1, SBC2). The registration database is located in the SBC configuration.

In the scenario illustrated inFIG. 1, two OS SBCs are provided in duplicated redundancy configurations (main or primary SBC1, SBC2and redundancy or secondary SBC3, SBC4pairs), two OSV servers (OSV1, OSV2) configured in a geo redundancy setup, and redundant network separated between access (WAN) and core (LAN) sides. This duplicated redundancy scenario serves an OSB which is responsible for providing access for both the SIP subscribers and gateways on a local side.

Herein, the main (or master) SBC configuration SBC1, SBC2is adapted to store the registration data of current SIP subscribers stored during their connections, and their port contents in a database. This database is shared between SBC1and SBC2via the non-proprietary redundancy protocol. The main OSV (i.e., OSV1) has the subscribers register configuration stored in its database and uses it for check and validation during the SIP registration process. The OSV's database comprises the main configuration (SBC1, SBC2) registration database for the subscribers registered via OSB.

We determined that a problem occurs when the primary network path is broken, i.e., the SBC1, SBC2configuration becomes inoperable. Reasons for that may be e.g., maintenance, system upgrade, link failure, hardware failure, power outage, disasters. Then, the alternative network path gets activated since neither the phones nor the OSV are aware of this situation. This leads to situations where the OSV or the phones at the branch are still trying to route calls via the primary path. As the re-registration period is typically 24 hours, the situation remains accordingly. Furthermore, double registrations of phones at the OSV occur.

In the scenario described before, this means that the main OSB becomes unavailable. Then, the OSB is forced to establish an alternative routing path for communication of the OSB via a redundancy SBC configuration (SBC3, SBC4) to the OSV server. Since the redundancy SBC configuration does not know the current subscribers database, calls will fail, and the subscribers will be forced to re-register again at OSV but via redundancy configuration (SBC3, SBC4). Besides that, registering with the new database will lead to duplicate registrations on both OSV redundancy pairs (i.e., OSV1, and OSV2).

SUMMARY

An object of the present invention is to provide a method and system which at least partially alleviate the problems outlined above.

This object is solved by embodiments of the method of providing backup for an OpenScapeVoice (OSV) configuration, a system for providing backup for an OSV configuration, a non-transitory computer readable medium, and a terminal device.

For example, an embodiment of a method of providing backup for an OpenScapeVoice (OSV) register configuration is provided, with at least one OpenScapeBranch (OSB), the at least one OSB providing communications to Session Initiation Protocol (SIP) subscribers, and communicating on a main routing path, via a main Session Boarder Controller (SBC) configuration (SBC1, SBC2) with an OSV server on the basis of SIP protocol, the OSB maintaining a database in which SIP subscribers currently communicating are registered, the method comprising the following steps:copying the database to a redundancy SBC configuration (SBC3, SBC4) on the basis of the SIP protocol,establishing an alternative routing path for communication of the OSB via the redundancy SBC configuration (SBC3, SBC4) to the OSV server, andcontinuing the providing of the communications of the SIP subscribers via the redundancy SBC configuration (SBC3, SBC4).

According to a preferred embodiment, the method steps are performed upon non-availability of the main or primary SBC configuration.

Preferably, the step of copying is performed using at least one SIP OPTIONS message.

The redundancy SBC may send at least one SIP message to the main SBC, and upon receiving at least one SIP OPTIONS message from the secondary or redundancy SBC, may start an un-registration process of listed subscribers. Specifically, in the un-registration process registrations for the subscriber's contacts with expiration equal to zero are sent. These registrations would use the main SBC configuration SBC1, SBC2virtual addresses and would remove the previous registrations.

According to another preferred embodiment, each of the SBC configurations, i.e., the main or primary and the redundancy or secondary SBC configurations, comprises a pair of two redundant SBCs, each of the pair of redundant SBCs synchronizing the respective SBCs.

According to still another preferred embodiment, the OSV is backed up by an additional OSV.

Further, an embodiment of a system for providing backup for an OpenScapeVoice (OSV) configuration is provided, with at least one OpenScapeBranch (OSB), the at least one OSB being adapted for providing communications to Session Initiation Protocol (SIP) subscribers, and for communicating on a main routing path, via a main Session Boarder Controller (SBC) configuration (SBC1, SBC2) with an OSV server on the basis of SIP protocol, the OSB being adapted for maintaining a database in which SIP subscribers currently communicating are registered, the system being adapted for:copying the database to a redundancy SBC configuration (SBC3, SBC4) on the basis of the SIP protocol,establishing an alternative routing path for communication of the OSB via the redundancy SBC configuration (SBC3, SBC4) to the OSV server,continuing the providing of the communications of the SIP subscribers via the redundancy SBC configuration (SBC3, SBC4).

Accordingly, embodiments of the inventive method and system can use the native SIP protocol signaling flow to mirror the subscribers database from the main SBC configuration to the secondary OS SBC configuration. It also uses the SIP protocol to establish a direct connection between the two redundancy systems and trigger a process of registration synchronization for the OSV redundancy pair. i.e., SBC1, SBC2, and SBC3, SBC4.

Thus, embodiments of the present invention can be configured to leverage on the SIP message OPTIONS in order to convey the registration information captured at the SBC towards the OSB in a proprietary information container. This allows the OSB on switchover due to WAN connectivity problem detected by also using SIP OPTIONS messages between the OSB and the SBC as heard beat in order to forward the registration information to the redundant SBC. Based on this information, the redundant SBC on the one hand re-registers the phones at the OSV and, on the other hand, “un-registers” the phones at the primary SBC via the direct connectivity provided at the enterprise network. Thus, the call routing problems are resolved and the registration databases are in synchronization at the primary and the redundant SBC.

Thereby, embodiments of the present invention creates a unique usage of synchronizing redundancy database information with the same signaling protocol (SIP) used for the peers. It also uses the SIP protocol body and its capabilities to relay private data on the same network and synchronize this data while it controls the current connections with the native SIP messages.

Further, embodiments of the inventive method does not need any special further network configuration and can be used natively.

Besides that, the inventive concept can be used in other embodiments that utilize en other SIP messages not only in order to provide the database mirroring, but also to check and exercise a redundancy backup path and improve the reliability and availability in the whole redundancy configuration.

Moreover, embodiments of the inventive method can be used not only for SIP registration databases, but for any database-like configuration, certificates, etc. Further, embodiments of the inventive method can be used to transfer any information from the main SBC configuration to the redundancy SBC.

Other details, objects, and advantages of the invention will become apparent as the following description of certain present preferred embodiments thereof and certain present preferred methods of practicing the same proceeds.

LIST OF REFERENCE NUMERALS

DETAILED DESCRIPTION

The scenario1illustrated inFIG. 1is composed of two OpenScape SessionBorder Controllers (OS SBCs). The OS SBCs can include a main OS SBC configuration2and a secondary OS SBC configuration3in a duplicated redundancy configuration (SBC1,2and SBC3,4pairs)2′,2″,3′,3″, two OpenScapeVoice (OSV) servers4,5configured in a geo redundancy setup (OSV1, OSV2) and a redundant network separated between access (WAN) and core (LAN) sides. This duplicated redundancy scenario serves an OpenScapeBranch (OSB) which is responsible to provide the access for both SIP subscribers7and gateways on a local office. A gateway can also be referred to as a “GW” herein.

It should be understood thatFIG. 1illustrates a Network address translation device (NAT) on the WAN side. Each NAT can be communicatively connected to an OSB Proxy6that is communicatively connectable to an OSB GW. It should be understood that each OSV server, GW, OSB proxy, and SBC (e.g. SBC1, SBC2, SBC3, and SBC4) can be a computer device that includes a processor connected to memory (e.g. flash memory or other non-transitory memory) and have other hardware (e.g. network transceivers, a display device, an input device, etc.).

The main master OS SBC (SBC1) indicated by reference numeral2′ is adapted to store the data registration of current SIP subscribers7along its connections and port contents. This database (DB) is shared with its backup OS SBC (SBC2) indicated by reference numeral2″ via a non-proprietary redundancy protocol. The main OSV4(OSV1) has the subscribers register configuration stored in its database and uses it for checking and validation during the SIP registration process.

When the main routing path8with the OS SBC redundancy pair (SBC1,2)2′,2″ becomes unavailable, the OSB uses the alternative routing path9with the secondary OS SBC redundancy pair (SBC3, SBC4) indicated by reference numerals3′,3″. Since the secondary pair3′,3″ does not know the current subscribers database, calls will fail and the subscribers7will be forced to re-register again. Besides this problem, there will be duplicated registrations on both OSV redundancy pairs (OSV1, OSV2) which will cause a dynamic problem and routing issues.

The method according to an embodiment of the present invention uses the native SIP protocol signaling flow to mirror the subscribers database from the main OS SBC redundancy configuration2′,2″ (pair SBC1, SBC2) to the secondary OS SBC redundancy configuration3′,3″ (pair SBC3, SBC4). Specifically, it uses the existent flow for the OPTIONS and 200 OK messages, and the SIP protocol by the SIP headers and MIME body to transport the data of the database. In addition, a new SIP flow for the re-register from SBC3,4to the OSVs is used. It also uses the same SIP process to establish a direct connection between the two redundancy systems and triggers a process of re-registration synchronization for the OSV redundancy pair4,5(OSV1, OSV2) in case of a network failover.

In this embodiment of the invention, the inventive method is implemented using the SIP OPTIONS messages which are already used to check the availability of the SBCs and OSVs paths. If no response (200 OK) is received by the OSB from SBC1,2, it will switch to the SBC3,4path. Herein, the MIME body of the message is used to transport the data needed to rebuild the registration database. It will be used to trigger the OS SBCs internally to send new REGISTER messages either to re-register or to un-register these subscribers7on the OSV redundancy pair.

OSB6adds a specific “request for registration database” header in the SIP OPTIONS message to the main OS SBC indicated by reference numeral2′. The SBC12′ uses this header to collect the current registration database (via a parsing script, for example), and sends it in the body contents of the OPTIONS' 200OK. The registration contains the contacts, expiration time, and all other registration data of each subscriber7. OSB6stores this database and on an outage, i.e., when no response for the SIP OPTIONS message to the SBC1and SBC2is received, it attaches it to the SIP OPTIONS message(s) for the secondary OS SBC (SBC3), indicated by reference numeral3′.

This system, i.e., the redundancy configuration SBC3, SBC4copies this registration database during the SIP parsing process from the initial SIP OPTIONS message from the OSB6. At the end of this process, it sends a series of REGISTER messages (via a script, for instance) to re-register the messages to the OSV4,5, and it forwards the same OPTIONS message(s) to the main SBC configuration2(SBC1, SBC2) to “un-register” the same database. This creates a direct main SBC configuration2↔secondary SBC configuration3communication in the core side without going through the OSVs4,5.

By doing this with every SIP OPTIONS message(s), the OSB6will be in synchronization with the latest registration database status and will allow to re-construct the whole registration path in case of network failures.

When the main OS SBC configuration2recovers its network connection, the same mechanism may be used to restore the registration path and re-synchronize the registration database.

In the embodiment ofFIG. 1, initially, all SIP signaling messages go from the OSB6to the SBC on the main SBC configuration2(virtual IP address: 100.64.0.4).

In more detail, the method of this embodiment of the invention comprises the following steps:

The OSB6uses the SIP OPTIONS messages (according to the SIP protocol) to retrieve and store the last registration status with the list of registered subscribers7.

Upon a network outage or any other connection with the main SBC configuration2at 100.64.0.4, the OSB6copies the registration database into the SIP OPTIONS message and sends it to the SBC3, indicated by reference numeral3′, on the secondary SBC configuration3(at virtual IP address: 100.64.8.4).

The secondary SBC configuration3will store the new registration database into its file directory. It will also send a SIP OPTIONS message to the main SBC configuration2with the same registration content.

Upon receiving the SIP OPTIONS message with registration content in the core side, the main SBC configuration2will start a un-registration process on the listed subscribers7.

Finally, the secondary SBC configuration3will start a re-registration process of all listed subscribers7. This step could also be performed based on the main SBC configuration2response.

At this point, both the secondary or redundancy SBC configuration3, indicated by reference numerals3′ (for SBC3) and3″ (for SBC4)′, and the OSV4,5pairs are synchronized with the registration database and shall be able to operate the new registrations and SIP calls.

The same process may be used when the connection with the main OS SBC pair2′,2″ is restored on the OSB6side.

While certain present preferred embodiments of the communication apparatus, communication system, communication device, non-transitory computer readable medium, and embodiments of methods for making and using the same have been shown and described above, it is to be distinctly understood that the invention is not limited thereto but may be otherwise variously embodied and practiced within the scope of the following claims.