Multiparty Conferencing with IP Multicast

The Multicast Conferencing Service Provider included with TAPI 3.0 provides support for IP multicast-based audio and video conferencing between multiple participants. The TAPI 3.0 rendezvous control provides additional COM interfaces that TAPI applications can use to access directory services such as Active Directory, and the Site Server ILS Service.

Conferences

The call model for multi-person conferences differs from conventional one-on-one calls. The conference is hosted by one of the participants, who takes the step of determining the conference name, its start and end times, and the list of participants. The host then publishes the conference on a server using his TAPI application (such as the Phone Dialer), and notifies the prospective participants that a conference is available for their participation.

Other participants might use their TAPI applications to visit the server and browse the list of conferences that are available for participation. At the designated time, participants use their TAPI applications to join the conference. TAPI provides all the infrastructure for audio and video streams to be transmitted and received using IP multicast.

IP Multicast

IP multicast is an extension of IP that allows for efficient conferencing. Without the use of IP multicast, a user wishing to broadcast data to N users must send data through N connections, as shown in Figure 15.4.

Figure 15.4 Sending Data Without IP Multicasting

Without IP multicasting, network bandwidth is wasted as the same data is transmitted individually to each recipient.

The total bandwidth required for multiparty recipient conferences in which all users are sending data goes up exponentially with the number of parties involved. This prevents widespread deployment of conferences involving multiple participants.

IP multicast takes advantage of the actual network topology to eliminate the transmission of redundant data through the same communications links. To reach a multicast group, a user sends a single copy of the data to a single group multicast IP address that reaches all recipients. No knowledge of other users in a group is necessary. To receive data, users register their interest in a particular multicast IP address with a multicast-aware router.

Multicast conferences are inherently more scalable because conference participants are not required to send additional audio and video copies as more participants are added.

Single Group IP Address

IP multicast uses a single group IP address to reduce network traffic. The value of this is illustrated in Figure 15.5, where six users who wish to participate in a conference are connected together by a number of routers.

Figure 15.5 Actual Network Topology

Without the use of multicast conferencing, all six users would send out five copies each of their audio and video data, resulting in 30 audio and 30 video streams which could potentially cause traffic congestion at some locations on the network.

IP multicast eliminates this volume of packets by using a single group IP address that can be joined by all six participants. Multicast aware routers route these one-to-many data streams efficiently by constructing a spanning tree in which there is only one path from one router to any other. Copies of the stream are made only when paths diverge, as shown in Figure 15.6.

Figure 15.6 IP Multicasting Spanning Tree

IP multicasting uses a spanning tree algorithm to minimize network traffic while ensuring that all multicast recipients receive the data stream.

Without multicasting, the same information must either be carried over the network multiple times, one time for each recipient, or broadcast to everyone on the network, consuming unnecessary bandwidth and processing.

Allocating Multicast Addresses

IP multicast uses Class D Internet Protocol addresses to specify multicast host groups, ranging from 224.0.0.0 to 239.255.255.255. Both permanent and temporary group addresses are supported. Permanent addresses are assigned by the Internet Assigned Numbers Authority (IANA) and include 224.0.0.1, the all-hosts group used to address all multicast hosts on the local network, and 224.0.0.2, which addresses all routers on a LAN. The range of addresses between 224.0.0.0 and 224.0.0.255 is reserved for routing and other low-level network protocols. Other addresses and ranges have been reserved for applications, such as 224.0.13.000 to 224.0.13.255 for NetNews. For more information, see RFC 1700.

Windows 2000 includes a Multicast Address Dynamic Client Protocol (MADCAP) server that can be used to allocate a unique multicast IP address for the duration of the conference. TAPI provides an API that allows applications to make such 'lease' requests to the server and obtain a multicast address without intervention from the user. Such requests can be made automatically while the host is creating the conference, ensuring the availability of a unique IP address that other participants can join to participate in the conference.

Note

A MADCAP server must be running somewhere on an organization's network to enable TAPI applications to obtain multicast IP addresses. For more information about MADCAP and its support in Windows 2000, see "Dynamic Host Configuration Protocol" in the TCP/IP Core Networking Guide .

Publishing Conference Objects

Once a host has determined the details of a conference, there are several possible ways to disseminate this information to potential participants. TAPI provides the means to publish these conferences on the Site Server ILS Service running on a centralized server, where all participants who have been granted access to the conference by the host are able to access this information. These conference objects are based on RFC 2327.

TAPI also provides the means for applications to access the Site Server ILS Service running on remote servers and allow users to browse the published conference objects and join conferences described in them.

The Phone Dialer application contains appropriate user interface elements to facilitate the creation, browsing, and joining of conferences.

Note

A Site Server ILS Service must be running on a server somewhere on an organization's network to enable TAPI applications to create conference objects.

Site Server ILS Service uses Active Directory to publish its own location on the network. TAPI also provides facilities to enable TAPI applications to locate Site Server ILS servers by querying Active Directory. This eliminates the need for individual users to know the specifics about the location of ILS servers on which conferences might be published by conference hosts.

Session Description Protocol

Session Description Protocol (SDP) is an IETF standard for announcing multimedia conferences. The purpose of SDP is to publicize sufficient information about a conference (time, media, and location information) to allow prospective users to participate if they so choose. Originally designed to operate over the Internet MBONE, SDP has been integrated with Active Directory and Site Server ILS service by TAPI 3.0, thereby extending its functionality to LANs.

An SDP descriptor advertises the following attribute information about a conference:

• Conference Name and Purpose

• Conference Time

• Conference Contact Information

• Media Type (video, audio, and so on)

• Media Format (H.261 Video, MPEG Video, and so on)

• Transport Protocol (RTP/UDP/IP, H.320, and so on)

• Media Multicast Address

• Media Transport Port

• Conference Bandwidth

A Session Description is broken into three main parts: a single Session Description, zero or more Time Descriptions, and zero or more Media Descriptions. The Session Description contains global attributes that apply to the whole conference or all media streams. Time Descriptions contain conference start, stop, and repeat time information, while Media Descriptions contain details that are specific to a particular media stream.

While traditional IP multicast conferences operating over the MBONE have advertised conferences using a push model based on the Session Announcement Protocol (SAP), TAPI 3.0 utilizes a pull-based approach using Windows 2000 Active Directory. This approach offers numerous advantages, among them bandwidth conservation and ease of administration.

Conference Security Model

The conference security system in TAPI 3.0 controls who can create, delete, and view conference announcements. Each object in Active Directory can be associated with an access control list (ACL) specifying object access rights on a user or group basis. By associating ACLs with SDP conference descriptors, as shown in Figure 15.7, conference creators can control who can enumerate and view conference announcements. User authentication is provided through Windows 2000 security.

Figure 15.7 SDPs and ACLs

Session descriptors are transmitted from the Site Server ILS server to the user using the LDAP protocol on port 1002. Windows 2000 IP Security connections can be used to secure this transmission, ensuring that the SDP conference descriptors are safe from eavesdroppers.

Important

Current implementations do not support encryption of media streams to prevent unauthorized eavesdropping of multicast packets during transit on the network.

Routing and Remote Access Service Considerations

Routers and dial-up Routing and Remote Access service connection servers must be explicitly configured to route or forward multicast packets and Internet Group Management Protocol (IGMP) requests made by clients wishing to join multicast conferences. IGMP enables clients to make requests for joining multicast group addresses in which they are interested).

For information about how to configure the Windows 2000 remote access server to enable multicast routing on a network, see "Remote Access Server" in this book.