CSE 126 Lecture 13

Multimedia Conferencing

Overview

Multimedia conferencing in its simplest form is a phone call. This type of conference has two parties and one medium (voice). The idea of multimedia conferencing extends this to multiple parties and multiple media (pronounced multimedia J ). Previous-generation multimedia conferencing systems were very large and expensive. Generally, they were given their own room and a dedicated high-bandwidth connection. Modern multimedia conferencing on the other hand is more PC based, with programs such as CU-See Me, where you can install a software program on your PC and join conferences on a common server.

Aspects of Control in Multimedia Conferencing

There are two aspects to controlling a multimedia conference:

1. Control Aspect: The control aspect refers to who is allowed to join a conference. This is also referred to as connection management.
2. Transmission Aspect: There are two different methods of transmission that need to be addressed. (1) is multicast where a message from one source is transmitted to multiple receivers. (2) is mixing (sometimes called bridging) where messages from multiple senders are all sent to a single receiver.

Control

Control stages are represented with state diagrams.

Take the telephone system as an example:

First, both the caller (one who calls) and the callee (one who is called) are in an idle state.

When the caller initiates the call, it causes a state transition in the callee, moving it to the ring state.

When the callee moves to the ring state, the caller's state is changed to the ringback state, where the caller hears that the callee is ringing.

If all goes well and the callee answers the phone, the callee enters the active state.

This causes another state transition, and the caller now moves to the active state. Now the channel is established and both can talk.

This is a simplefied scenario, with little error control (imagine the caller hanging up in various states of the diagram), but you get the idea.

Extensions

There are many extensions to a simple conferencing system. Let's take a look at some of them:

• Multi-Party: Who has permission to speak? This is sometimes called Floor Control. In this paradigm, whoever "has the floor" has permission to speak. The floor can be granted in several different ways:
• Round Robin: Each participant is given a chance to speak in each round.
• First Come First Serve: Requests are processed in order they are received.
• Conference Controller: A conference controller is an individual who has the ability to determine who has permission to speak. If the controller wishes to leave the conference, he/she must elect another controller to replace him/her.
• Multi-Level: This extension allows multiple conferences to exist, and one may exist without the other. It also permits privacy, where a sub-conference may be cut off from the main conference.

• Symmetric/Asymmetric: Suppose one party uses audio only, and another uses audio and video. A symmetric system would not allow the two to communicate, however an asymmetric system would allow them to communicate despite the differences. In general, a conferencing system should support asymmetric communication due to bandwidth limitations.
• Heterogeneous/Homogeneous: In a heterogeneous system, you may have media conversion, e.g. a voice signal is also sent in text using a speech to text converter for those clients who cannot support voice. Note that this is different from Asymmetric in the fact that conversion is necessary here where in Asymmetric is not converting, it is only sending a portion of the signal.
• Static/Dynamic: A static conference does not allow parameters (such as the number of participants to change), while a dynamic conference does.
• Transient/Persistent: If the number of participants drops below 2, transient conferences will be dropped. A persistent conference will persist with fewer than two participants. AT&T has a system called the room paradigm for persistent, dynamic conferencing. Think of the room as a constant. No matter who comes and goes, the room is still there and remains available for use.
• Synchronous/Asynchronous: Synchronous conferences have fixed bounds on the time between messages, while asynchronous conferences (e.g. group e-mail) has no bounds. Each message in an asynchronous system may take a vastly different amount of time to arrive to all users.

Obviously, there are a lot of extensions to consider in a conferencing system. It is important to remember that each time you add a feature to a conferencing system, it's state diagram will become vastly more complex.

Say for example that we want to create a conferencing environment for our class to be taught over. What features might this system need? Well, first we obviously need to allow multiple parties. We should also allow Asymmetric communication because we will most likely have many different levels of bandwidth and hardware used. The class should be persistent, so the "room" is always available at the specified time. During lectures, students should be able to leave and join at will (Dynamic), however during exams the class should be static. We should also allow synchronous and asynchronous attendance so that those that want to attend and participate real-time can do so, while others can just rely on a version stored somewhere that they can playback at any time. All other features are probably not necessary and would just add a large degree of complexity to the system.

Synchronization:

2-way talk (e.g. UNIX talk) is easy, synchronization is not really an issue.

Multi-party talk, even as simple as 3-way talk, is hard. How do we ensure that messages arrive to all users in the correct order if each user has a variable network speed? To solve this problem, let's take a look at the idea of Centralized Control.

In centralized control, we have a centralized conference server, which is responsible for keeping synchronization between its users. Each message sent to the server has a timestamp, and the server is responsible for ensuring that messages arrive in order, so that if User A's message has a time stamp t, user B's reply to that message must have a timestamp later than t, and so on. Serializing these timestamps is a big bottleneck. To make it scalable, consider a hierarchical system:

Here, delay increases with the number of levels in the hierarchy. Since interactive communication requires a delay less than around 100-150 ms, this limits us in the number of users we can support.