Multipoint control unit (MCU) failure detection and rollover

• US 7,937,442 B2
• Filed: 10/25/2006
• Issued: 05/03/2011
• Est. Priority Date: 09/22/2006
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Sekaran, Dhigha, Narayanan, Sankaran
• Primary Examiner(s): Patel; Ashok B
• Assistant Examiner(s): EDWARDS, LINGLAN E
• Application Number:
  US11/552,905
• Publication Number:
  US 20080077666A1
• Time in Patent Office: 1,651 Days
• Field of Search: 709/204, 709/221, 709/224, 709/226
• US Class Current: 709/204
• CPC Class Codes: H04L 12/1827 Network arrangements for conference optimisation or adaptation

Abstract

A method, system, and architecture for detecting MCU failures is provided. The conference system detects the failure of MCUs that have been allocated to provide shared conference resources to conferences that are being hosted by the conference system. The conference system utilizes the sending and receiving of “heartbeat” messages between the MCUs and the conference server pool to detect failed MCUs. Upon detecting the failure of an MCU, the conference system performs a “rollover” of the conferences which were being serviced by the failed MCU to another available MCU. The conference system may then identify the clients which were connected to the failed MCU and notifies the clients that an MCU rollover has occurred and a new (replacement) MCU is available in order that these clients can reconnect and reestablish their media sessions.

Claims

1. A computer-implemented method for detecting failure of a shared conference resource in a conference system, the method comprising:

receiving at a conference server pool from a shared conference resource a keep-alive message sent by the shared conference resource, the shared conference resource servicing a plurality of associated conferences;

upon receiving the keep-alive message, updating information regarding keep-alive messages sent by the shared conference resource on a conference store;

upon determining that a keep-alive message has not been received from the shared conference resource for at least a keep-alive interval;

identifying the plurality of conferences that are associated with the shared conference resource;

indicating that each identified conference is suspected as being unhealthy;

sending a get conference request from a conference server in the conference server pool to the shared conference resource to determine a health status of the conferences serviced by the shared conference resource;

upon receiving a response to the get conference request,

for each of the identified conferences that are listed in the response as being healthy, indicating that the identified conference is healthy

for each of the identified conferences that are not listed in the response as being healthy, indicating the identified conference is unhealthy,

if the conference server does not receive a response to the get conference request, indicating that that each identified conference is unhealthy;

when at least one identified conference is indicated as unhealthy,

requesting by the conference server a replacement shared conference resource to service the unhealthy conference; and

rolling over each unhealthy conference associated with the shared conference resource to the replacement shared conference resource;

wherein at least one of the identified conferences is rolled over to be serviced by the replacement shared conference resource and at least one of the identified conferences continues to be serviced by the shared conference resource.

2. The method of claim 1, wherein,

upon receiving at the conference server pool from the shared conference resource the keep-alive message sent by the shared conference resource, forwarding the keep-alive message to a conference server in the conference server pool, and

further wherein the conference server updates information regarding keep-alive messages sent by the shared conference resource on a conference store.

3. The method of claim 2,

wherein the conference server is stateless, and

further wherein the keep-alive message is forwarded to the stateless conference server by a conference server pool load balancer.

4. The method of claim 1, wherein the request for the replacement conference resource is made to a multipoint control unit factory.

5. The method of claim 1 further comprising,

upon determining that a shared conference resource has performed a fast-restart, sending from a conference server in the conference server pool to the shared conference resource a get conference request message,

the get conference request message identifying a conference associated with the shared conference resource and requesting an indication of whether the identified conference is being serviced by the shared conference resource.

6. The method of claim 1 further comprising:

for each indicated unhealthy conference,

identifying clients in the unhealthy conference; and

sending to each identified client an indication of the replacement multipoint control unit to connect to.

7. The method of claim 1, wherein the request for the replacement multipoint control unit is made to a multipoint control unit factory.

8. The method of claim 1, further comprising:

identifying clients that are participating in the unhealthy conference;

notifying the clients of the unhealthy conference;

sending, from the conference server to the identified clients, an indication of the replacement shared conference resource to connect to;

connecting, by the identified clients to the replacement shared conference resource to continue the conference.

9. The method of claim 1, further comprising:

in receiving a response to the get conference request, indicating that the specific conference associated with the shared conference request is healthy.

10. The method of claim 1, wherein, the conference server uses conference state information maintained in the conference store for the unhealthy conference to recreate, on the replacement shared conference resource, a conference state that was associated with the unhealthy conference.

11. A computer-implemented method for detecting failure of a shared conference resource in a conference system, the method comprising:

receiving at a conference server pool from one or more multipoint control units keep-alive messages sent by the multipoint control units and updating information regarding the keep-alive messages sent by the multipoint control units on a conference store, wherein each multipoint control unit provides a shared conference resource to a conference hosted by the conference server pool;

determining by a conference server in the conference server pool suspected multipoint control units from the keep-alive messages sent by the multipoint control units, wherein the conference server determines that a multipoint control unit is a suspected multipoint control unit upon determining that a keep-alive message has not been received from the multipoint control unit for at least a keep-alive interval; and

for each suspected multipoint control unit,

sending a get conference request from the conference server to the suspected multipoint control unit to determine a health status of a specific conference serviced by the shared conference resource;

wherein, the get conference request message including a list of conferences serviced by the suspected multipoint control unit which are suspected to be unhealthy;

if the conference server does not receive a response to the get conference request message, or if the conference server receives a response to the get conference request message indicating that at least one identified conferences is unhealthy;

requesting by the conference server a replacement multipoint control unit to service the unhealthy conferences;

rolling over the unhealthy conferences to the replacement multipoint control unit

wherein at least one of the conferences is rolled over to be hosted by the replacement multipoint control unit and at least one of the identified conferences continues to be hosted by the multipoint control unit.

12. The method of claim 11, wherein the keep-alive messages received at the conference server pool are processed by a conference server pool load balancer.

13. The method of claim 12,

wherein the conference server pool load balancer forwards the received keep-alive message to an appropriate conference server in the conference server pool, and

further wherein the appropriate conference server updates information regarding the keep-alive message on the conference store.

14. The method of claim 11, wherein the conference store is remote to conference servers in the conference server pool.

15. The method of claim 11, wherein the conference server determines that a multipoint control unit is a suspected multipoint control unit upon determining that the multipoint control unit performed a fast-restart.

16. A conferencing system that detects failure of a multipoint control unit, comprising:

a conference store for maintaining information regarding keep-alive messages sent by multipoint control units; and

at least one conference server that includes;

a memory storing computer-executable instructions implementing a module that

identifies a suspected multipoint control unit from the keep-alive messages sent by the multipoint control unit;

identifies a list of suspect conferences serviced by the suspected multipoint control unit;

sends a get conference request to the suspected multipoint control unit to determine a health status of the list of suspect conferences;

upon receiving a response to the get conference request indicating that at least one conference is unhealthy,

requests a replacement multipoint control unit to service the unhealthy conference; and

rolls over the indicated unhealthy conference to the replacement multipoint control unit

wherein at least one of the identified conferences is rolled over to be serviced by the replacement multipoint control unit and at least one of the identified conferences continues to be serviced by the multipoint control unit;

a processor that executes the computer-executable instructions store in the memory.

17. The system of claim 16, wherein the conference server determines that a multipoint control unit is a suspected multipoint control unit upon determining that the multipoint control unit has failed to send a keep-alive message for at least a keep-alive interval.

18. The system of claim 16, wherein the conference server determines that a multipoint control unit is a suspected multipoint control unit upon determining that the multipoint control unit has performed a fast-restart.