CINEMA - Automated Conference Network

Huwei Zhang
Columbia University
Computer Science Department
503 West 121th Street, Apt#43D
New York, NY 10027
Email:hz80@columbia.edu

Abstract

Columbia InterNet Extensible Multimedia Architecture (CINEMA) provides a test bed for different multimedia and Internet telephony applications. We need some mechanism to implement the load balancing in the SIP conference servers to achieve better performance. When the participants in the conference grows, we can dispatch the partipants to the least loaded server and bring up new server when it is necessary.

Introduction

The longer term goal of the project is to build a system which automatically adds new servers and transfers existing participants to new servers as the group size grows using the audio/video conferencing server. The new servers should be chosen to be well-positioned in respect to the members to be transferred, e.g., by using UDP round trip delay, path length or packet loss measurements. In this document we describe how to implement a simple version of the system: Find the server which has capacity to host the new conference from the current active conference servers. Later, we can choose the server that has capacity AND has a good path properties to the participant at connect time.

Related work


Old Conference Server System

This project is based on the sipconf audio conference server built by Kundan Singh and Gautam Nair. We extend the following functionality in the current version:

  • algorithm to choose the best server for the conference
  • add "REDIRECT" service to the conference server

    Background


    Conference Server with REDIRECT service

    To implent the load balancing in conference servers when the size of participants in conference grows, we need some mechanism to evaluate the current load in each server and make decision as where to direct the participant and when to bring up new server if all the servers in the conference is overloaded.

    Currently, information for the conference servers are not presented in the database, thus make it difficult to evaluate the current conferece servers, conference members in the servers and related QOS information.

    Also, current system have only one table entry for each conference, even if it has multiple instances. Each conference, such as irt-meeting@cs.columbia.edu, can (or should be able to) have multiple instances. For example, irt-meeting@cs might meet once a week, Wednesday evening at 6 for 2 hours. Each such meeting would be a separate instance.

    Architecture

    To make server information presented in the database, we need a server database. Each conference should simply have an entry pointing to its server, which is then registered on the proxy.(E.g., if the conference acm@cs.columbia.edu is on conductor, conductor would register with sipd as Contact acm@conductor.cs.columbia.edu.)

    In addition, we need another table for each conference instance. The file upload area and message board (in the future) would be for the whole conference, while the conference recording, for example, would be specific to one instance of the conference. This table will store the user QOS measurements, indexed by conference-instance and user.


    Conference Server Database Design

    In summary, we should have:

  • ConfServer - a new table for the conference servers 
      - host running the server
  - server capacity
  • Whole conference - a table for whole conference statistics 
      - date and time with repeat indication ("every Wednesday", "every other day")
  - voting
  - message board
  - action items (part of calendar)
  - file upload
  - membership list
  - event group that the conference refer to
  • Conference Instance - a new table for each instance(one time, limited duration) that contains 
      - event for the instance in calendar 
  - start and ending time
  - host running the conference
  - pointer to recording
  • QOS - a table that has user QOS measurements, indexed by conference-instance and user. Generate one record for each RTCP report received. 
      - user
  - conference instance
  - QOS values (from RTCP report):
    - number of RTP packets received
    - number of RTP packets sent
    - packet loss fraction reported by the participant via RTCP RR
    - # of packets sent as claimed by the RTCP SR (this allows to detect losses 
      seen by the mixer)
    - jitter reported by the participant in RTCP RR
    The sipconf module:

    This is the controller module for the conference server. It connects the SIP and RTP libraries. This is the module that the external clients interact with to setup the SIP call.

    We add following API's to the MySIP library:
    int GetEventID (int event_group_id) :
    This function return the event_id for the given event_group that currentTime is in between the start_time and end_time, return 0 if no match found. 
    int GetEventGroupID () :
    This function return the event_group_id for the conference that the user want to join when a new call arrives, return 0 if no match found. 
    void *CreateConfInstance () :
    This function create the conference instance for the conference in the database, this is called when a new SIP call arrives and the instance for the conference that the user want to join hasn't been created yet. 
    void *CreateConfInstance () :
    This function create the conference instance for the conference in the database, this is called when a new SIP call arrives and the instance for the conference that the user want to join hasn't been created yet. 
    char *GetConfInstanceServer () :
    This function find the server for the conference if a instance is currently active, this is called when a new SIP call arrives. It will search for the conference server for the conference in the confinstances table, if find the match, return the server for the conference, a NULL string is returned if no match found. 
    char *GetLeastLoadServer () :
    This function find the least loaded server from the conference servers, this is called when a new "ad hoc" conference is created via INVITE. It will search the database for the current load for all the conference servers and find the server with least users count. 
    char *GetServerHasCapacity () :
    This function find the server which still have enought capacity to satisfy the bandwidth requirement for a new conference, this is called when a new conference with known size is created via INVITE. It will search the database for the current load for all the conference servers and find the server with the maximum left capacity. 
    char *RunScheduleAlgorithm () :
    This function run the schedule algorithm to find the best server for the new conference instance. This is called when a new SIP call arrives to join a conference instance which hasn't been created yet. In this case, we will create a new instance for the conference, and then run the algorithm to find the best server for the conference instance:
  • the least loaded server for the "ad hoc" conference created via INVITE
  • the server with maximum left capacity for conference with known size

    Program Documentation

    The program documentation is available as a man page.

    Future Work and Extensions

    1. Record RTCP report in the confqos table for the quality of service from the conference servers.
    2. Develop algorithm for evaluating the path property and the quality of service.
    3. Build conference server system with more dynamic features such as distribute single conference across difference servers, automatically add new server when current system is overloaded, dynamically REDIRECT conference user based on the quality of service, etc.

    Conference Server Future Extension

    Installation Instructions

    Platform: UNIX system, Sun 5.8 

       1. Setup 
   mkdir sun-sipconf 
   cd sun-sipconf

   2. configure
   ..configure --with-mysql=/proj/irt-gc4/mysql/SunOS

   3. make 
   make sipconf

    References

    1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,"SIP:session initiation protocol," Request for Comments (Proposed Standard)2543, Internet Engineering Task Force, Mar. 1999.
    2. Kundan Singh, Gautam Nair, Sipconf Overview
    3. Columbia InterNet Extensible Multimedia Architecture

    Updated: 12/14/2001 By Huwei Zhang