Dugki Min(dkmin@pluto.konkuk.ac.kr)
Department of Computer Science and Engineering, Konkuk University, Mojin-dong,
Kwangjin-ku, Seoul
Korea
Eunmi Choi(emchoi@han.ac.kr)
School of Computer Science and Electronic Engineering, Handong University, Add.3,
Namsong-ri, Heunghae-eub, Puk-ku, Pohang City
Korea
Youngtae Han(ythan@pluto.konkuk.ac.kr)
Department of Computer Science and Engineering, Konkuk University, Mojin-dong,
Kwangjin-Ku, Seoul
Korea
Kyungsik Park(oslinux@kkucc.konkuk.ac.kr)
Department of Computer Science and Engineering, Konkuk University, Mojin-dong,
Kwangjin-Ku, Seoul
Korea
Jinhyang Kim(ghkim@pluto.konkuk.ac.kr)
Department of Computer Science and Engineering, Konkuk University, Mojin-dong,
Kwangjin-Ku, Seoul
Korea
Abstract
In order to integrate existing video conferencing systems, this paper proposes a distributed and scalable open architecture for integrated video conferencing, called the ADVICE (AuDio VIdeo Conferencing Environment). The ADVICE is not itself a video conferencing server, but an infrastructure that provides a global integrated video conferencing environment where a user can communicate with others who are in heterogeneous video conferencing service domains. As a bridge to the integrated architecture, the essential component, called "Mediator" is designed. Also, we investiages the ADVICE CORBA services for global conferencing. For the communication backbone infrastructure, the ADVICE uses the CORBA technology.
กก
Innovation in video conferencing technologies, such as high speed networking and data compression, has been matured for developing research and commercial video conferencing and collaboration applications which supply an environment to communicate and work with other users in a virtual internet space. At the advent of MBone (Multicast Backbone)[1], which has been invented for the research purpose of testing IP multicasting, various conferencing tools working on MBone have been developed. VAT (Visual Audio Tool)[2], VIC (Video Conference)[3], NV (NetVideo)[4], and IVS (INRIA Videoconferencing System)[5] are those conferencing applications. In commercial side, a number of video conferencing products have been introduced each of which is an independent applications supporting audio/video communications and sharing tools. Internet Phone, CUSeeMe, and NetMeeting are some examples of general commercial products.
As various video conferencing services become popular in the Internet society, the existing video conferencing systems have turned out to hardly fulfill users' requirements due to their incompatable protocols and lacks of service functionality. One of the significant drawbacks is that most of existing video conferencing systems restrict their services only to the users with the client applications provided by the vendor. It is because each video conferencing system utilizes its own protocol which is pre-defined by the vendor independently. However, users would like to communicate with others no matter what client software they use or what video conferencing system they connect to. Due to the effect of network externality, the quality of video conferencing service could be improved by expanding the sphere of communication over a number of conferencing service domains, tools, and protocols. Another drawback of the existing video conferencing systems is that they provide only a few of convenient functions, such as on-line user directory, session and conference management, asynchronous message communication, group management, and private secure communication.
In order to overcome these limitations and drawbacks of the existing video conferencing systems, we propose a distributed and scalable open video conferencing architecture, called ADVICE (AuDio VIdeo Conferencing Environment). The ADVICE is not itself a video conferencing server, but an infrastructure that provides a global integrated video conferencing environment where a user can communicate with others who are in heterogeneous service domains. Suppose that there are several heterogeneous video conferencing service domains using different protocols. In order to construct the ADVICE, we supply a "mediator" to each video conferencing service domain. The mediator provides various meaningful operations to its associated video conferencing server for integrated global video conferencing services. It transforms data format to match heterogeneous protocols, and performs as a gateway to obtain rich global video conferencing services in the ADVICE. Vendors can easily implement their Mediators by means of the ADVICE CORBA services whose interfaces are well defined by the standard CORBA IDL[6].
We also investigate the design of the ADVICE CORBA services for global integrated video conferencing services. The services concerned in this paper are global information services and global session and conference management services. The global information service deals with two types of information: global on-line user directory and global session information. Based on the global on-line directory information, one can find if its session counterparts are ready to start a global conferencing session. The session and conference management service provides operations related to session lifecycle and conference control. All these ADVICE CORBA services have standard CORBA interfaces and follow the same protocol. They are designed to have a scalable architecture to accommodate a huge number of users by distributing load over multiple servers.
The following section shows the ADVICE architecture in view of system design. Section 3 presents the Mediator. After describing clients' requirements, the components of Mediator are introduced in detail. Section 4 shows the ADVICE CORBA services, that is, GICS, SS, and MRouter, by describing the detailed functions and working flows. The concluding remarks are in the last section.
Figure 1 shows the overall picture of the ADVICE architecture. The ADVICE is composed of a number of Video Conferencing System(VCS) domains that use heterogeneous protocols. A VCS domain represents an existing video conferencing system that has a video conferencing server and a number of its clients. For example, VocalTec's Internet Phone System or Microsoft's Netmeeting System could be a VCS domain. The video conferencing server in a VCS domain, called VCServer, provides various video conferencing services to its clients. VCServer can be a computer or a cluster of distributed computers. In general, when a client application starts, it makes a direct connection to the VCServer and receives the current directory information on the on-line users and on the working sessions in the VCS domain. When a client selects one item out of the directory, it makes a direct connection to the chosen one. The client can perform a video conferencing by exchanging audio/video streams or chatting/whiteboard data with the connected counterpart. If the selected one is a session, the client joins in the session. Some existing VCS domains provide users with an option to create interest groups, where a user can easily find other on-line users with similar interests.
Figure 1. The ADVICE Architecture
Since the existing video conferencing systems are developed independently by different vendors, they use heterogeneous conferencing protocols. In order to make heterogeneous VCS domains interoperable, bridges are needed in the middle, which translate a protocol to another. There are two possible ways to bridge a number of heterogeneous protocol domains. The first approach, called the immediate bridging[7], places a bridge for each pair of domains, as shown in Figure 2 (a). In this approach, two domains communicate directly to each other over a single bridge that fully translates one's protocol to the other's. This method is good if there are a few domains, but not scalable for a large number of domains since the number of bridge types grows up to the number of combinations of distinct pairs taken out of the heterogeneous domains. Unlike the immediate bridging, the second approach, called the mediate bridging[7], uses half bridges that translate a specific protocol to a common protocol. The ADVICE architecture employs the later approach to solve the interoperability problem of heterogeneous VCS domains. Figure 2 (b) redraws Figure 1 in view of mediate bridging integration, where "mediators" take the role of half bridge. All heterogeneous domains have bridges to the common protocol, called the ADVICE protocol. The number of bridge types only grows up to the number of different domains.
 |
 |
| (a) Immediate Bridging | (b) Mediate Bridging |
Figure 2. Two Types of Bridging
As the communication backbone infrastructure among the VCS domains, the ADVICE uses CORBA(Common Object Request Broker Architecture)[8]. CORBA is a distributed object computing standard leaded by OMG(Object Management Group). A CORBA object developed according to the CORBA technology has a standard interface defined by the OMG IDL(Interface Definition Language) and its unique object reference. Thus, through the CORBA ORB infrastructure, a CORBA object can be accessed by its object reference and its methods can be invoked by the standard interfaces. That is, CORBA ORB infrastructure makes CORBA objects interoperable in a language-transparent and location-transparent manner. Since a CORBA ORB is interoperable with other CORBA ORBs, a CORBA object can co-work with any CORBA object distributed on an interoperable CORBA ORB. In Figure 1 of the ADVICE architecture, the Mediator of each VCS domain is a CORBA object that communicates to the outside world of the VCS domain through the CORBA infrastructure. The CORBA ORB of each VCS domain should be set up for interoperation with other CORBA ORBs in ADVICE.
Each VCS domain has to implement its own Mediator, which performs the following functions for global conferencing over heterogeneous VCS domains through CORBA infrastructure. First, it supplies global information, such as a directory of global on-line users or global sessions, to the VCServer, so that the VCServer delivers the information to its clients. In fact, the global information is collected in Global Information and Control Server(GICS) and transferred to all Mediators. Next, it transfers outgoing data to the outside of the VCS domain, i.e., it delivers text data of whiteboard or chatting to Session Server(SS) and audio/video stream data to MRouter, respectively. It also disseminates incoming data to the participants of the corresponding session. Besides, as explained above, it performs a function of half bridge for all data traffic passing through it. That is, it translates a domain-specific conferencing protocol to the common ADVICE protocol, and vice versa. Section 3 describes the Mediator in more detail.
The ADVICE architecture offers a number of ADVICE CORBA services to be used by Mediators. These ADVICE CORBA services are provided by cooperating CORBA objects that are scattered on several distributed servers. In this paper, we consider three distributed servers: Global Information and Control Server(GICS), Session Server(SS), and Multicasting Router(MRouter). GICS serves for global directory information service on on-line users and working sessions, communicating with Directory Objects (DOs) of Mediators. It also performs load balancing for scalable session management. SS manages and controls a number of on-going global sessions, communicating with the corresponding Session Objects (SOs) of Mediators. It also reflects text data of whiteboard and chatting to their participants. MRouter provides the multicasting service for audio/video streams of on-going sessions. Since audio/video streams require real-time transfer of huge data, it is not appropriate to use the CORBA infrastructure. Thus, audio/video streams multicast to the corresponding SOs through the MRouters, and then the SOs disseminate the stream data to the participants. There is a GICS on the ADVICE architecture and one or more MRouters and SSs. Section 4 describes these servers in more detail.
In this section, we investigate the details of the Mediator. In order to help to understand functions of Mediator, we first describe clients' requirements of Mediator that are needed for global conferencing in ADVICE. And then we introduce the major components of Mediator with more detailed explanation about their operations.
3.1 Clients' Requirements
In order to describe clients' requirements of Mediator explicitly, we illustrate a number of possible cases. Figure 3 shows a snapshot of global video conferencing on ADVICE. All clients are connected to their VCServers for video conferencing. Each VCS domain has a Mediator through which it is connected to CORBA ORB. A Session Server(SS) is composed of two kinds of objects: Session Manager(SM) and Session Controller(SC). A Session Manager manages the lifecycle of Session Controllers and a Session Controller manages a global on-going session. Suppose that there are three clients who already participate in a global session SA: client A1 from VCS domain 1, client A2 and A3 from VCS domain 2. Note that VCS domains 1 and 2 have SO A to serve the participants of the global session SA, but VCS domain 3 does not have SO A due to no participant. In this situation, let us consider the following four cases. Case 1) Client A4 on VCS domain 2 joins SA. Case 2) Client A5 on VCS domain 3 joins SA. Case 3) Client A1 on VCS domain 1 leaves SA. Case 4) Client B1 on VCS domain 1 creates a new session, say SB.
Figure 3. A snapshot of global video conferencing in the ADVICE
In all the cases except Case 3, clients want to see global directory information of on-line users and the list of on-going global sessions. After seeing the directory, clients join a global session in Cases 1 and 2, and create a new session in Case 4. Also, a participant in a global session sends to or receives from other participants various types of data, such as text data of whiteboard/chatting or audio/video stream data. Another requirements are for a participant to see the details of necessary information about the session, such as the types of employed media, and to leave the session in the middle of session or at the end of session.
3.2 Components of the Mediator
Mediator acts as a bridge through which a client in a VCS domain can start or hold a global conference with clients in other VCS domains. A Mediator is composed of two types of CORBA objects: Directory Object(DO) and Session Object(SO). The interfaces and behaviors of these objects are pre-defined in the design stage of ADVICE. Their implementations, however, might be different, depending on the underlying VCS systems and left as a duty of their domain vendors. In order to serve their clients for global video conferencing, DO and SO, as CORBA objects, cooperate with the ADVICE CORBA service objects through the CORBA infrastructure.
3.2.1 DO (Directory Object)
DO is in charge of global directory services in the associated VCS domain as well as managing other objects in the Mediator. When a Mediator starts to operate in a VCS domain, DO makes a direct connection to the VCServer. It also finds GICS and MRouter through the CORBA naming service and remembers the IOR (Interoperable Object Reference) of GICS and the IP of MRouter. If a MRouter exists in the same CORBA ORB domain, the MRouter is found. Otherwise, any MRouter that responses faster is used. DO also registers its IOR to GICS, so as to obtain broadcasting global information from GICS. To manage global directory information services, DO keeps uploading to GICS its local directory of domain on-line users and session information, and updating its information on global on-line users and global sessions that is received from GICS. Whenever a client in its domain wants to see the global directory information, DO delivers it to the client.
When a client joins a global session, DO makes the client connect to the corresponding SO. As in Case 1 of Figure 3, when client A4 on VCS domain 2 joins the global session SA, DO makes client A4 connect to SO A which already exists for clients A2 and A3. In contrast, Case 2 shows that SO A does not exist in VCS domain 3. When client A5 joins SA, DO creates SO A and gives SO A the IP of MRouter and the IOR of Session Controller, SC A, on Session Server SS1. Using the IP, SO A makes a direct connection to the MRouter. As in Case 3, when a client creates a global session, SB, DO forwards the client's session creation request to GICS. GICS performs load balancing to find a proper SS, say SS2, and creates SC B on the SS2 for the new global session SB. DO receives the information about global session SB from GICS and creates SO B in the Mediator. The afterward operations of DO are the same as in Case 2.
3.2.2 SO (Session Object)
SO is another type of object in a Mediator, which manages a global session and data transmission. It translates the format of incoming or outgoing data of the VCS local domain to the common ADVICE format, and transfers the data to the appropriate destinations. SO also provides the detailed information of global session to its participants on request.
Whenever there is a client who joins a global session, there should be a SO that is in charge of the global session on the VCS domain. If SO does not exist, DO creates a new SO that connects the client to the global session. Thus, the number of SOs in a Mediator is as many as the number of global sessions used by the clients in the VCS domain. If the workload caused by the assigned SOs is too heavy that a single computer cannot handle alone, the VCS domain can use several computers and distribute the SOs. This is possible because SOs operate independently. Thus, the Mediator of ADVICE is scalable no matter how many global sessions its clients join.
SO performs a number of operations during a session as follows. Once a SO is created by DO, the SO is informed of the MRouter's IP and the IOR of the Session Controller (SC) by DO. The SC is the associated object in Session Server(SS), which is in charge of a global session. Using the IP, SO makes a direct connection to the MRouter for multicasting audio/video streams during the session. The IOR is used whenever SO invokes methods of SC through CORBA infrastructure. Another operation of SO is that SO maintains a directory of clients who participate in the global session. Whenever a client joins or leaves the associated session, SO updates its directory and sends an updating message to the SC. Also, SO updates information about the global session, such as types of employed media, which is transferred from the associated SC during the session. SO provides this detailed session information to clients whenever it is requested. When the last participant in the session leaves, SO informs the SC of the leaving and destroys itself.
While the global session goes on, SO performs the role of data translation and transmission. For integration of heterogeneous conferencing protocols of several VCS domains, SO converts the data format to the common one whenever text or stream data pass through it. Depending on the data type, SO transfers data in different manners. Since the text data of chatting or whiteboard data are usually small and should be errorless, SO transfers the text data to SC through the CORBA infrastructure. In contrast, SO transfers the audio/video data streams to MRouter. Since the audio/video streams are usually huge and insensitive to errors, they are routed to all participants in a multicast fashion by MRouters. When a SO receives text data from SC or AV stream data from MRouter, it disseminates them to its participants in the session.
ADVICE contains three components to provide ADVICE CORBA services: GICS, SS, and MRouter. These components operate on distributed servers, cooperating with Mediators on VCS domains.
4.1 Global Information & Control Service: GICS
GICS maintains global information and performs load balancing of session servers. There exists a GICS in ADVICE. For the sake of fault tolerance, ADVICE may have a mirror of GICS. GICS communicates with DOs in Mediators through CORBA ORB and gives the following services.
4.1.1 Global Information Service
GICS maintains two types of global information. The first is the global directory of on-line users, which is referred by a client when he wants to know that its counterparts are ready for a global conference. Whenever a new client connects to or disconnects from a VCServer, the associated DO updates its local on-line user information and delivers it to GICS. By using this local on-line user information from DO, GICS updates the global directory of on-line users and broadcasts to all DOs periodically or in a pre-defined manner. The other type of global information is the list of on-going global sessions. This information is updated whenever a session is created or destroyed by the associated SS. In order to update this information, GICS communicates with all DOs in a pre-defined manner like the case of global directory.
4.1.2 Global Control Service
When a session needs to be created, GICS checks the loads of SSs and selects a SS having the smallest load. Then, GICS lets the SS create a Session Controller, which is in charge of the new session. Since SCs operate independently, they are able to run on any SS. Thus, by simply adding more SSs at any place on the CORBA infrastructure, ADVICE can increase its ability to serve a larger number of global sessions.
4.2 Session Management Service: Session Server (SS)
SS is in charge of managing sessions and providing session related services. It is possible to have a number of SSs in ADVICE. SS communicates with GICS and SOs in Mediators. SS is composed of the following two components: Session Manager(SM) and Session Controller(SC).
4.2.1 Session Manager (SM)
Each SS contains a Session Manager that manages the lifecycle of SCs and informs GICS of session creation and termination. When receiving a creation message of global session, SM spawns a SC that is in charge of the new session, and informs GICS. SM maintains information of the spawned SCs. When an existing global session is requested for termination, SM destroys the SC and informs GICS.
4.2.2 Session Controller (SC)
Session Controller performs all services for an on-going global session. When a SO sends a session joining or leaving message of a client, SC updates its user list. It also informs all SOs of the status change of the global session, so that SOs can response the clients' requests of session information immediately. Another operation of SC is to control the authority of using a shared resource by a token. SC controls and audits the flow of token by assigning, receiving back, and checking the redundancy and the loss of token. SC informs all participants of the state of token through the corresponding SOs. Also, SS is in charge of transmitting and disseminating text data that is necessary to be error-free, such as chatting and whiteboard data. In addition, for on-demand services after a global session, SC can record all the traffics during the global session.
4.3 Multicasting Service: MRouter
During a global session, all participants communicate with one another by transmitting audio/video data. Compared to text data, audio/video stream data is insensitive to transmission error, but larger and sensitive to timing. Thus, we need to design a separate communication service that provides more fast and efficient group audio/video communication. Multicast Routers, called MRouters, are to this purpose. MRouters route audio/video data streams to the corresponding SOs in a multicasting fashion. Compared to point-to-point data dissemination by SC through CORBA ORB, it reduces network traffic and achieves faster transmission[9].
In this paper, we proposed the ADVICE as an open integrated video conferencing architecture. The ADVICE is an infrastructure of global video conferencing environment where a user can communicate with others who are in heterogeneous conferencing domains. Over various video conferencing domains, the ADVICE provides convenient services for global video conferencing, such as global information services and global session and conference management services. The ADVICE also has a scalable architecture to accommodate a huge number of users by distributing load over multiple servers. In this context, this paper presented the communication infrastructure and the architecture of global services of the ADVICE that are based on the CORBA technology. Each vendor expands its existing video conferencing system into the ADVICE by adding its own Mediator. The Mediator provides various meaningful operations to its associated video conferencing server for integrated global video conferencing services. The implementation of Mediator is system-specific, but its interface follows the CORBA standard. Detailed function and organization of the Mediator were presented. We also described the ADVICE CORBA services provided by GICS, SS and MRouter.