System and method for protecting against failure through geo-redundancy in a SIP server

• US 7,844,851 B2
• Filed: 12/13/2007
• Issued: 11/30/2010
• Est. Priority Date: 12/13/2006
• Status: Active Grant

• Current Assignee: BEA Systems Incorporated (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Kramer, Reto, Langen, Anno R., Mehra, Vinod, Cosmadopoulos, Ioannis
• Primary Examiner(s): Beausoliel; Robert
• Assistant Examiner(s): Riad; Amine
• Application Number:
  US11/956,094
• Publication Number:
  US 20080183991A1
• Time in Patent Office: 1,083 Days
• Field of Search: 714/4
• US Class Current: 714/4.1
• CPC Class Codes: G06F 11/2028 eliminating a faulty processor or activating a spare
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: H04L 65/1104 Session initiation protocol [SIP]
• CPC Class Codes: H04L 67/1095 Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 67/142 Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
• CPC Class Codes: H04L 69/40 for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection management of faults, events, alarms or notifications in data switching networks H04L41/06

Abstract

The SIP server deployment can be comprised of an engine tier that provides high throughput processing and a state tier that maintains SIP state data in a set of partitions and replicas. Two sites of SIP server deployments can be configured, each being remotely located with respect to the other. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Engines in the primary site can generate hints for the state replicas which can be in turn responsible for replicating the SIP session state. The replicas can choose to follow or disregard the generated hints. Upon failure of the primary site, calls can be routed from the failed primary site to the secondary site for processing. Similarly, upon recovery, the calls can be re-routed back to the primary site.

Claims

1. A computer implemented method for protecting against failure through geographical redundancy, said method comprising:

maintaining a primary site and a secondary site of network server nodes, each of said primary site and secondary site including an engine tier that processes transactions and a state tier that maintains call state data associated with said transactions;

processing at least one transaction by the engine tier of said primary site;

determining, by said engine tier of the primary site, that a transaction boundary of said transaction has been reached; and

replicating, by said state tier of the primary site, the call state data associated with said transaction from the primary site to the secondary site upon determining that said transaction boundary has been reached;

wherein replicating, by said state tier of the primary site, the call state data associated with said transaction from the primary site to the secondary site further includes;

placing a message on a Java Messaging Service (JMS) queue by a single replica node in a partition on said state tier on the primary site, said message containing said call state data to be replicated;

reading said message from the JMS queue by at least one engine in said engine tier on the secondary site;

persisting said call state data contained in the message by said engine on the secondary site to at least one of;

a database and a state node in said state tier on the secondary site; and

marking said call state data as being local to the primary site in order to distinguish from call state data being actively managed in said secondary site.

2. The method according to claim 1 wherein determining, by said engine tier of the primary site, that a transaction boundary of said transaction has been reached further includes:

determining, by an engine node in the engine tier of the primary site, that no more transactions are likely to immediately follow that would alter the state data associated with said transaction;

generating, by said engine node, a hint indicating that a transaction boundary has been reached; and

transmitting said hint by said engine node to at least one state replica node in the state tier of the primary site.

3. The method according to claim 2 wherein determining, by said engine tier of the primary site, that a transaction boundary of said transaction has been reached further includes:

receiving said hint by the state replica node in the state tier of the primary site; and

determining whether to acquiesce to said hint and replicate the state data associated with said transaction by the state replica node.

4. The method according to claim 1 further comprising:

detecting a failure of said primary site of network server nodes; and

routing calls from the primary site to the secondary site such that the secondary site is configured to retrieve and activate call state data that has been replicated from the primary site wherein the activated call state data maintains a marker to denote that the activated call state data has been replicated from the primary site.

5. The method according to claim 4 further comprising:

detecting recovery and start up of said primary site after said failure; and

re-routing said calls that were routed to the secondary site, back to the primary site upon detection of said recovery by using said marker.

6. The method of claim 1, wherein the network server nodes of the primary site continuously process calls routed to the primary site in accordance with a global routing policy.

7. The method of claim 6, further comprising:

detecting a catastrophic failure of the entire primary site and modifying the global routing policy to reroute said calls to the secondary site, wherein the network server nodes of the secondary site employ the replicated state data to process the re-routed calls.

8. The method of claim 1, wherein the primary site and the secondary site are separate server domains located geographically remotely from each other such that a catastrophic failure of the entire primary site will not affect an ability of the secondary site to process said transactions, and wherein each server domain comprises a cluster of interconnected server devices that process said transactions.

9. A computer readable storage medium encoded with a set of instructions for protecting against failure through geographical redundancy, wherein said instructions, when executed by one or more processors, cause the one or more processors to carry out the steps of:

maintaining a primary site and a secondary site of network server nodes, each of said primary site and secondary site including an engine tier that processes transactions and a state tier that maintains call state data associated with said transactions;

processing at least one transaction by the engine tier of said primary site;

determining, by said engine tier of the primary site, that a transaction boundary of said transaction has been reached; and

replicating, by said state tier of the primary site, the call state data associated with said transaction from the primary site to the secondary site upon determining that said transaction boundary has been reached;

wherein replicating, by said state tier of the primary site, the call state data associated with said transaction from the primary site to the secondary site further includes;

placing a message on a Java Messaging Service (JMS) queue by a single replica node in a partition on said state tier on the primary site, said message containing said call state data to be replicated;

reading said message from the JMS queue by at least one engine in said engine tier on the secondary site;

persisting said call state data contained in the message by said engine on the secondary site to at least one of;

a database and a state node in said state tier on the secondary site; and

marking said call state data as being local to the primary site in order to distinguish from call state data being actively managed in said secondary site.

10. The computer readable storage medium of claim 9, wherein determining, by said engine tier of the primary site, that a transaction boundary of said transaction has been reached further includes:

determining, by an engine node in the engine tier of the primary site, that no more transactions are likely to immediately follow that would alter the state data associated with said transaction;

generating, by said engine node, a hint indicating that a transaction boundary has been reached; and

transmitting said hint by said engine node to at least one state replica node in the state tier of the primary site.

11. The computer readable storage medium of claim 10, wherein determining, by said engine tier of the primary site, that a transaction boundary of said transaction has been reached further includes:

receiving said hint by the state replica node in the state tier of the primary site; and

determining whether to acquiesce to said hint and replicate the state data associated with said transaction by the state replica node.

12. The computer readable storage medium of claim 9, further encoded with instructions for:

detecting a failure of said primary site of network server nodes; and

routing calls from the primary site to the secondary site such that the secondary site is configured to retrieve and activate call state data that has been replicated from the primary site wherein the activated call state data maintains a marker to denote that the activated call state data has been replicated from the primary site.

13. The computer readable storage medium of claim 12, further encoded with instructions for:

detecting recovery and start up of said primary site after said failure; and

re-routing said calls that were routed to the secondary site, back to the primary site upon detection of said recovery by using said marker.

14. The computer readable storage medium of claim 9, wherein the network server nodes of the primary site continuously process calls routed to the primary site in accordance with a global routing policy.

15. The computer readable storage medium of claim 14, further encoded with instructions for:

detecting a catastrophic failure of the entire primary site and modifying the global routing policy to reroute said calls to the secondary site, wherein the network server nodes of the secondary site employ the replicated state data to process the re-routed calls.

16. The computer readable storage medium of claim 9, wherein the primary site and the secondary site are separate server domains located geographically remotely from each other such that a catastrophic failure of the entire primary site will not affect an ability of the secondary site to process said transactions, and wherein each server domain comprises a cluster of interconnected server devices that process said transactions.