Mechanism for transparent real-time media server fail-over with idle-state nodes

• US 8,009,555 B2
• Filed: 02/25/2009
• Issued: 08/30/2011
• Est. Priority Date: 02/25/2009
• Status: Active Grant

• Current Assignee: Red Hat, Inc. (International Business Machines Corporation)
• Original Assignee: Red Hat, Inc. (International Business Machines Corporation)
• Inventors: Ralev, Vladimir Angelov
• Primary Examiner(s): Pham; Chi H.
• Assistant Examiner(s): HOM, SHICK C
• Application Number:
  US12/392,904
• Publication Number:
  US 20100214908A1
• Time in Patent Office: 916 Days
• Field of Search: None
• US Class Current: 370/217
• CPC Class Codes: G06F 11/2025 using centralised failover control functionality
• CPC Class Codes: G06F 11/2041 with more than one idle spare processing component
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups

Abstract

In one embodiment, a mechanism for transparent real-time media server fail-over with idle-state nodes is disclosed. In one embodiment, a method includes replicating a start time of a request related to a bidirectional stream of media sent to an original master media server, receiving notification of selection as a new master media server after failure of the original master media server, determining an offset time by subtracting the replicated request start time from a current time, and resuming playback of the request at the offset time within the request.

Claims

1. A computer-implemented method performed by a new master media server, comprising:

replicating a start time of a request related to a bidirectional stream of media sent to an original master media server, wherein the original master media server performs playback of the request at the start time;

receiving notification of selection as the new master media server after failure of the original master media server;

remaining idle until both of the failure of the original master media server and the selection as the new master media server;

determining an offset time by subtracting the replicated request start time from a current time; and

resuming playback of the request at the offset time within the request.

2. The method of claim 1, wherein the request includes at least one of playback of a file, a scheduled task, and generation of a dual tone multi-frequency (DTMF) sequence signal.

3. The method of claim 1, wherein the original master media server and the new master media server are developed on a JAVA platform.

4. The method of claim 3, wherein the original master media server and the new master media server utilize a JAVA Management Extension (JMX) Application Programming Interface (API) and a Service Logic Execution Environment (SLEE) container.

5. The method of claim 1, wherein the original master media server and the new master media server are controlled by a JBoss™

Communications Platform (JBCP) application server.

6. The method of claim 1, wherein the original master media server receives the bidirectional stream of media from a media gateway.

18. The method of claim 1, wherein the request start time is replicated by the new master media server, wherein the notification of selection as the new master media server is received by the new master media server, wherein the offset time is determined by the new master media server, and wherein the playback is resumed by the new master media server.

19. The method of claim 1, wherein the new master media server does not execute all of the requests received by the original master media server and does not replicate the state of the original master media server.

7. A system, comprising:

a media server controller;

a master media server controlled by the media server controller to receive a bidirectional stream of media from a caller; and

a backup media server coupled to the master media server and controlled by the media server controller, the backup media server operable to;

replicate a start time of a request related to the bidirectional stream of media, wherein the master media server performs playback of the request at the start time;

receive notification from the controller of selection as a new master media server after failure of the master media server;

remain idle until both of the failure of the master media server and the selection as the new master media server;

determine an offset time by subtracting the replicated request start time from a current time; and

resume playback of the request at the offset time within the request.

8. The system of claim 7, wherein the request includes at least one of playback of a file, a scheduled task, and generation of a dual tone multi-frequency (DTMF) sequence signal.

9. The system of claim 7, wherein the master media server and the new master media server are developed on a JAVA platform.

10. The system of claim 9, wherein the master media server and the new master media server utilize a JAVA Management Extension (JMX) Application Programming Interface (API) and a Service Logic Execution Environment (SLEE) container.

11. The system of claim 7, wherein the controller is a JBoss™

Communications Platform (JBCP) application server.

12. The system of claim 7, wherein the master media server receives the bidirectional stream of media from a media gateway communicably coupled to the master media server and the backup media server.

20. The system of claim 7, wherein the backup media server does not execute all of the requests received by the master media server and does not replicate the state of the master media server.

13. An article of manufacture comprising a non-transitory machine-readable storage medium including data that, when accessed by a machine, cause the machine to perform operations comprising:

replicating a start time of a request related to a bidirectional stream of media sent to an original master media server, wherein the original master media server to perform playback of the request;

receiving notification of selection as a new master media server after failure of the original master media server;

remaining idle until both of the failure of the original master media server and the selection as the new master media server;

determining an offset time by subtracting the replicated request start time from a current time; and

resuming playback of the request at the offset time within the request.

14. The article of manufacture of claim 13, wherein the request includes at least one of playback of a file, a scheduled task, and generation of a dual tone multi-frequency (DTMF) sequence signal.

15. The article of manufacture of claim 13, wherein the original master media server and the new master media server are developed on a JAVA platform.

16. The article of manufacture of claim 15, wherein the original master media server and the new master media server utilize a JAVA Management Extension (JMX) Application Programming Interface (API) and a Service Logic Execution Environment (SLEE) container.

17. The article of manufacture of claim 13, wherein the original master media server and the new master media server are controlled by a JBoss™

Communications Platform (JBCP) application server.

21. The article of manufacture of claim 13, wherein the request start time is replicated by the new master media server, wherein the notification of selection as the new master media server is received by the new master media server, wherein the offset time is determined by the new master media server, and wherein the playback is resumed by the new master media server.

22. The article of manufacture of claim 13, wherein the new master media server does not execute all of the requests received by the original master media server and does not replicate the state of the original master media server.