MULTIPOINT CONTROL UNIT (MCU) FAILURE DETECTION AND ROLLOVER

• US 20080077666A1
• Filed: 10/25/2006
• Published: 03/27/2008
• 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
• Granted Patent: US 7,937,442 B2
• Time in Patent Office: Days
• 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:

sending, periodically, from a shared conference resource to a conference server pool a keep-alive message;

receiving at the conference server pool from the shared conference resource the keep-alive message sent by the shared conference resource and updating information regarding keep-alive messages sent by the shared conference resource on a conference store;

upon determining that keep-alive messages have not been received from the shared conference resource for at least a keep-alive interval, sending from a conference server in the conference server pool to the shared conference resource a get conference request, the get conference request 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;

if the conference server does not receive a response to the get conference request, indicating that the identified conference associated with the shared conference resource is unhealthy; and

if the conference server receives a response to the get conference request, indicating that the identified conference associated with the shared conference request is healthy.

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 further comprising:

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

receiving an indication of the replacement shared conference resource to service the unhealthy conference.

5. The method of claim 4 further comprising:

identifying clients in the unhealthy conference; and

sending to each identified client an indication of the replacement shared conference resource to connect to.

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

7. 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.

8. The method of claim 1 wherein the get conference request identifies a list of conferences associated with the shared conference resource and requests an indication of health of the conferences in the list of conferences, and further comprising:

if the conference server does not receive a response to the get conference request, indicating that the conferences in the list of conferences are unhealthy; and

if the conference server receives a response to the get conference request, identifying the conferences in the list of conferences that are indicated as not being serviced by the shared conference resource and indicating that the identified conferences are unhealthy.

9. 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; and

for each suspected multipoint control unit,

sending from the conference server in the conference server pool to the suspected multipoint control unit a get conference request message, the get conference request message including a list of conferences associated with the suspected multipoint control unit and requesting an indication of health of the conferences in the list of conferences;

if the conference server does not receive a response to the get conference request message, indicating that the conferences in the list of conferences are unhealthy; and

if the conference server receives a response to the get conference request message, identifying the conferences in the list of conferences that are unhealthy based on the response to the get conference request message and indicating that the identified conferences are unhealthy.

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

11. The method of claim 10, wherein the conference server pool load balancer forwards the a 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.

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

13. The method of claim 9, 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.

14. The method of claim 9, 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.

15. The method of claim 9 further comprising:

for each indicated unhealthy conference,

requesting by the conference server a replacement multipoint control unit to service the conference, the replacement multipoint control unit providing the same conferencing resource as the suspected multipoint control unit that previously serviced the unhealthy conference; and

receiving an indication of the replacement multipoint control unit to service the unhealthy conference.

16. The method of claim 15 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.

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

18. 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,

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

identifies a list of suspect conferences associated with the suspected multipoint control unit;

sends to the suspected multipoint control unit a get conference request, the get conference request requesting an indication of whether the suspected multipoint control unit is servicing the suspect conferences identified in the get conference request;

upon failing to receive a response to the get conference request, indicates that the conferences identified in the get conference request are unhealthy; and

upon receiving a response to the get conference request, identifies the conferences in the get conference request that are unhealthy based on the response to the get conference request and indicates that the identified conferences are unhealthy.

19. The system of claim 18, 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.

20. The system of claim 18, 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.