NetMeeting 2.1 Resource Kit

This chapter describes the communication and conferencing standards supported by Microsoft® NetMeeting™. For each industry standard supported by NetMeeting, the following topics are discussed:

• A description of the standard, its benefits, and interoperability 

• The standard's architecture, including communication and conferencing protocols and components 

• How NetMeeting supports the standard in its platform 

Overview

Developers, hardware vendors, Web professionals, and customers have expressed their need for Internet communications and workgroup conferencing capabilities built on accepted industry standards. Industry experts agree—the time for proprietary products has passed, and the time to build standards-based, 100% interoperable, multimedia communication and conferencing products is here. As the marketplace rallies around standards, Microsoft takes a leadership role in developing standards-based products and solutions that extend communication and collaboration over the Internet and corporate intranets.

This chapter focuses on NetMeeting as a standards-based platform by first providing background information about how NetMeeting incorporates this standards vision and also about the types of organizations that develop these industry standards. Then, this chapter provides more detailed information about the following industry standards that NetMeeting supports:

• The International Telecommunications Union (ITU) T.120 standard for data collaboration and conferencing 

• The ITU H.323 standard for audio and video communication and conferencing 

• The Internet Engineering Task Force (IETF) lightweight directory access protocol (LDAP) standard for accessing directory services 

NetMeeting Standards Vision

Standards are critical to achieving the vision of NetMeeting—to create and popularize a new type of multimedia communications. To achieve this vision, a real-time communication and conferencing product must be developed with open standards so that users can connect with each other as easily and reliably as using a telephone. Consumers of this technology expect and demand that all products will operate error-free, and that every connection will succeed. Standards ensure this experience.

With standards, a product from one vendor can provide a guaranteed level of compatibility with products from other vendors. Vendors can continue to build compatible add-on products that will successfully interoperate with different real-time communication and conferencing products. Depending on the standards that these products support, users can potentially share applications and information, see each other with video, talk to one another, or perform all of these functions simultaneously.

Standards Organizations

The Microsoft NetMeeting team is an active member of organizations that promote industry standards. The following organizations are at the forefront of standards development for communications and conferencing products:

International Telecommunications Union (ITU). Governments and the private sector coordinate global telecommunication networks and services through the ITU, headquartered in Geneva, Switzerland. This international organization coordinates, develops, regulates, and standardizes global telecommunications and organizes regional and world events.

For more information about the ITU, see their Web site at https://www.itu.ch/  . This site includes detailed publications about ITU recommendations for the T.120 and H.323 standards. Only paying members can access the majority of the ITU standards information from the ITU Web site.

Internet Engineering Task Force (IETF). The IETF is the protocol engineering and development arm of the Internet. This organization is a large, open, international community of network designers, operators, vendors, and researchers concerned with the evolution of Internet architecture, as well as the smooth operation of the Internet. The IETF maintains working groups for research and technical study.

For more information about the IETF, see their Web site at https://www.ietf.org/  . Refer to this site for Internet drafts of IETF standards documents, including drafts for LDAP specifications.

International Multimedia Teleconferencing Consortium Inc. (IMTC). The IMTC is a nonprofit corporation founded to promote the creation and adoption of international standards for multipoint document and video teleconferencing. This organization provides a forum for its worldwide members to develop product specifications and educate others on standards-based development. The IMTC and its members promote a "Standards First" initiative to guarantee interoperability for all aspects of multimedia teleconferencing.

For more information about the IMTC, see their Web site at https://www.imtc.org/  . This site provides informative documents on the T.120 and H.323 standards, which are particularly helpful for people who are not paying members of the ITU. The IMTC also sponsors mailing lists and activity groups that foster standards-based product development and interoperability.

Developing and Ratifying Standards

A division of the ITU, called the Telecommunication Standardization Sector (ITU-T), is responsible for developing and ratifying international conferencing standards. The ITU-T maintains a hierarchical structure of Study Groups, Work Parties, and Questions. On the lowest level, Questions are composed of industry professionals worldwide who propose standards and address standards issues. Questions are included within selected Work Parties, which oversee these efforts. At the highest level, 16 Study Groups define the primary development areas and consist of groups of Work Parties.

A Question develops a proposal in the form of a White Document to establish a new standard or enhance an existing one. The proposal is submitted to the Work Party for review. If the Work Party accepts the "determined" proposal, it is submitted for a vote. Voting members are representatives from United Nations countries. All members must agree to the proposal. Following this initial vote, a one-year period enables members to provide their feedback before the final vote. The final vote by letter ballot (two-thirds majority required) determines whether the proposal is ratified.

T.120

This section contains information about the T.120 standard and its architecture, and how NetMeeting supports T.120 for data conferencing. It also explains T.120 protocols and supported topologies.

What is the T.120 Standard?

The ITU T.120 standard is made up of a suite of communication and application protocols developed and approved by the international computer and telecommunications industries. These protocols enable developers to create compatible products and services for real-time, multipoint data connections and conferencing. T.120-based applications enable many users to participate in conferencing sessions over different types of networks and connections.

Depending on the type of T.120 product, they can make connections, transmit and receive data, and collaborate using compatible data conferencing features, such as application sharing, conferencing whiteboard, and file transfer. Microsoft and more than 100 other major companies support the development of products and services using the T.120 standard.

Benefits

The demand for standards-based products and services is based on the many benefits that standards provide to consumers. The following list describes some of the primary benefits of developing under the T.120 standard:

• T.120 ensures that many participants can send and receive data in real time without any errors in data transmission. Users can expect this reliability over many types of supported connections, including TCP/IP and null modem.

• For multipoint data conferencing, the T.120 standard supports a variety of common topologies, including cascaded, star, and daisy-chain connections. To learn more about these topologies, see "Topologies" later in this chapter. 

• Developers can create applications with T.120 alone, or in combination with other ITU standards, such as the H.323 standard for audio and video conferencing. 

Interoperability

One of the most important features of the T.120 infrastructure is the interoperability of products and services that support the standard. This interoperability extends both to networking and applications. For more information about T.120 interoperability, see Chapter 9, "Product Interoperability."

T.120 Architecture

The IMTC Web site documents the T.120 architecture. For detailed information, visit https://www.imtc.org/i/standard/papers/i_wtpg03.htm ** **. The following diagram illustrates the T.120 architecture. This architecture follows the open systems interconnection (OSI) model, which specifies a series of layers, including lower level networking protocols for connecting and transmitting data that provide their services to higher level application protocols.

T.120 is an umbrella standard that encompasses a series of communication and application standards. The following standards and components make up the T.120 infrastructure:

T.121. This standard provides a generic application template (GAT), which specifies a common set of guidelines for building application protocols. T.121 describes how an application protocol, such as T.127 for file transfer, registers itself with the conference, applies its capabilities locally and remotely, and interoperates and negotiates capabilities with other applications. The GAT defines the management facility that controls the resources used by application functions. To ensure application consistency, T.121 is a required standard for products developed under T.120. The ITU also recommends that nonstandard applications incorporate T.121 to provide product interoperability.

T.122. The T.122 standard defines the multipoint services that enable one or more participants to send data as part of a conference. These multipoint services are implemented by T.125, which provides the mechanism for transporting the data. Together, the T.122 and T.125 standards make up the T.120 multipoint communication services (MCS). T.122 supports various conference topologies; for more information, see "Topologies" later in this chapter.

T.123. T.123 is responsible for transporting and sequencing data, and for controlling the flow of data across networks, including connect, disconnect, send, and receive functions. For data transport, T.123 defines a series of network interface profiles, including profiles for TCP/IP and null modem connections. Also, T.123 provides an error-correcting mechanism that ensures accurate and reliable data delivery.

T.124. This standard provides the generic conference control (GCC) for initiating and administering multipoint data conferences. The GCC performs the following functions:

• Serves as the information center, directing people and data in and out of conferences and monitoring progress so that the latest conference information is always available.

• Maintains lists of conference participants and their applications; the GCC identifies compatible applications and features so that products can interoperate. 

• Tracks MCS resources so that conflicts do not occur when conference participants use multiple applications, such as T.127 for file transfer and T.128 for application sharing. 

T.125. This standard specifies how data is transmitted within a conference. T.125 defines the private and broadcast channels that transport the data and ensures accurate and efficient communication among multiple users. T.125 implements the multipoint services defined by T.122.

T.126. The T.126 standard defines the methodology for using a conferencing whiteboard. This standard specifies how an application sends and receives whiteboard information, in either compressed or uncompressed form, for viewing and updating among multiple conference participants. The role of T.126 is to manage the multiuser workspace provided by the whiteboard.

T.127. This standard defines how files are transferred simultaneously among conference participants. T.127 enables one or more files to be selected and transmitted in compressed or uncompressed form to all or selected participants during a conference.

T.128. The T.128 standard (not shown in diagram) was proposed by Microsoft as an addition to the T.120 standard and has been determined by the ITU-T. T.128 specifies an application sharing protocol, defining how participants in a T.120 conference can share local applications. T.128 enables multiple conference participants to view and collaborate on shared applications.

Node Controller. The node controller is the command and control entity for T.120 and is responsible for administering network-level events, including the management of conference connections, participants, and conference data. This controller takes command of the other T.120 layers, particularly the transport layer, and uses the GCC, MCS, and other protocol services to manage the entire conference. The node controller acts as the translator, ensuring that events are interpreted and ordered correctly.

Topologies

The T.120 architecture supports several topologies that define how users connect to a conference and transmit data during the conference. The following diagram illustrates three common topologies: star, daisy-chain, and cascaded. These topologies represent the types of connections typical of NetMeeting conferences.

One of the participants in the conference is assigned as the top provider (conference host). The top provider's application is responsible for handling the global resources in the conference and also for sequencing data, if necessary. The top provider is determined within the initial connection between the first two participants. The location of the top provider and how the other participants are connected to the top provider differentiates the various topologies.

With NetMeeting, the person initiating the call is the top provider. The previous diagram illustrates the relationship of this top provider to other NetMeeting nodes in the various conference topologies; many other combinations of top provider and conference nodes are possible. NetMeeting actually initiates the call and determines whether a conference is already running. If no conference is running, NetMeeting creates one locally with the person initiating the call as the top provider. If a conference is running, NetMeeting notifies the person, who then has the option of joining the remote conference. Also, NetMeeting provides a Host Meeting feature (Call menu), which determines the top provider automatically based on the selected conference host rather than on the caller order.

Data flows according to the conference topology, which is determined by how each connection in the conference is established ("who calls who"). For example, in the diagram, the following order of calls establishes the conference topology:

• A (top provider) initiates calls to B and C. 

• Then, B calls D and E (or D and E each call B). 

• C calls F and G (or F and G each call C). 

There is only one top provider in a conference. After the top provider (A) is established, that computer remains the top provider throughout the conference. Note that two conferences cannot be joined together. Therefore, if C called F and G first, it would not be possible for them to join the conference with A, B, D, and E.

During data conferencing, if B shared an application with the other conference participants, data would flow simultaneously to the adjoining connections (A, D, and E). Then, data would continue to flow outward to the remaining connections. Also, any two connections within the conference can initiate audio and video conferencing. NetMeeting enables audio and video switching, so that participants can switch the pair sharing audio and video.

If B hangs up or is removed from the conference, D and E are also removed. D and E may remain conferenced together, though, if they were connected with audio and video in the original session. D and E would not have data conferencing, however, because this function is removed when B hangs up.

How NetMeeting Uses the T.120 Standard

Microsoft developed NetMeeting data conferencing features based on the T.120 infrastructure, enabling NetMeeting to interoperate with other T.120 standards-based products. T.120 protocols are the building blocks for the following NetMeeting functions:

• The ability to establish and maintain NetMeeting data connections. Two or more participants can establish a NetMeeting connection. Within the conference, T.120 protocols manage the sequencing and flow of data transported by NetMeeting connections. T.120 ensures that data is accurately and reliably transmitted between conference nodes. 

• Built-in data conferencing applications. NetMeeting conference participants can use T.120-based applications (which sit on top of T.120), such as file transfer based on the T.127 standard and application sharing based on T.128. Note that NetMeeting does not support T.126 currently; this support is expected in a future NetMeeting version. 

• Support for multiuser conferences. Many people can join a NetMeeting data conference for communication and collaboration. The conference host (top provider) in NetMeeting provides the node that manages participants and their applications.

• Capability to interoperate across networks and platforms. T.120 interfaces enable NetMeeting and other standards-based products to communicate across common networks using TCP/IP without platform restrictions.

Microsoft continues its efforts to enhance and extend the application of T.120 protocols. The standards groups that define T.120 are now working on the next generation of the protocols, and Microsoft is very active in these efforts.

H.323

This section contains information about the H.323 standard and its architecture, and how NetMeeting supports H.323 for audio and video conferencing. You can also gain an understanding of H.323 protocols and the interoperability of H.323-based products.

What is the H.323 Standard?

H.323 is an ITU standard that sets forth a specification for terminals (PCs), equipment, and services for multimedia communication over networks, which do not provide a guaranteed quality of service. H.323 terminals and equipment can carry real-time video, audio, and data, or any combination of these elements. This standard is based on the IETF real-time protocol (RTP) and real-time control protocol (RTCP), with additional protocols for call signaling and data and audiovisual communications.

Products that use H.323 for audio and video enable you to interconnect and communicate with other people over the Internet, just as people using different makes and models of telephones can communicate over PSTN lines. H.323 defines how audio and video information is formatted and packaged for transmission over the network. Standard audio and video codecs encode and decode input/output from audio and video sources for communicating between nodes.

Also, H.323 specifies T.120 services for data communications and conferencing within and next to an H.323 session. Most importantly, this T.120 support means that data handling can occur in conjunction with H.323 audio and video, or separately.

Benefits

Leading the audio and video teleconferencing industry, H.323 products and services offer many benefits to consumers. The following list describes some of the benefits that distinguish H.323:

• Microsoft and more than 120 leading companies have announced their intent to support and implement H.323 in their products and services. This broad support establishes H.323 as the leading solution for audio and video conferencing over the Internet. 

• Products and services developed by multiple vendors under the H.323 standard can interoperate without platform limitations. H.323 conferencing clients, bridges, servers, and gateways will support this interoperability.

• H.323 provides multiple audio and video codecs that format data according to the requirements of various networks, with different bit rates, delays, and quality options. Users can choose the codecs that best support their computer and network selections. 

• The addition of T.120 data conferencing support to the H.323 specification means that products developed under H.323 can offer a full range of multimedia functions, with both data and audiovisual conferencing support.

Interoperability

Just as telecommunication standards enable people with telephones from different vendors to call anyone around the world, the H.323 standard will enable the same level of interoperability for audio and video conferencing on the Internet. For more information about H.323 interoperability, see Chapter 9, "Product Interoperability."

H.323 Architecture

The IMTC Web site documents the H.323 architecture; for detailed information, visit https://www.imtc.org/i/standard/itu/i_h323.htm  . The following diagram illustrates the H.323 architecture. This architecture defines a set of specific functions for framing and call control, audio and video codecs, and T.120 data communications. The diagram also shows audio and video equipment interfaces, as well as the network interface.

H.323 terminal architecture, shown in the illustration, is the most common implementation of the H.323 specification. This same architecture can also be implemented for H.323 multipoint control units (MCUs), gateways, and gatekeepers. For more information about these H.323 components, see "H.323 MCUs, Gateways, and Gatekeepers" in this chapter.

Framing and Call Control

The H.225.0, Q.931, and H.245 standards make up the System Control Unit, which provides for call control and framing capabilities.

H.225.0. This standard defines a layer that formats the transmitted video, audio, data, and control streams for output to the network and retrieves the received video, audio, data, and control streams from the network. H.225.0 uses the packet format specified by IETF RTP and RTCP specifications for logical framing, sequence numbering, and error detection as part of audio and video transmissions. Logical framing defines how the protocol "frames" or packages the audio and video data into bits (packets) for transport over a selected communications channel. Sequence numbering determines the order of data packets transported over a communications channel.

After initiating a call, one or more RTP/RTCP connections are established. Multiple streams enable H.225.0 to send and receive different media types simultaneously, each with their own frame sequence numbers and quality of service options. Support for RTP and RTCP enables the receiving node to synchronize the received packets in the proper order so the user hears or sees the information correctly.

The H.225.0 standard also includes registration, admission, and status (RAS) control, which is used to communicate with the gatekeeper. A RAS signaling channel enables the connections between the gatekeeper and H.323 components. The gatekeeper controls H.323 terminal, gateway, and MCU access to the LAN by granting or denying permission to for H.323 connections. For more information about gatekeepers, see "H.323 MCUS, Gateways, and Gatekeepers" in this chapter.

Q.931. The Q.931 protocol defines how each H.323 layer interacts with peer layers, so that participants can interoperate with agreed upon formats. The Q.931 protocol resides within H.225.0. As part of H.323 call control, Q.931 is a link layer protocol for establishing connections and packaging or framing data. Q.931 provides a method for defining logical channels inside of a larger channel. Q.931 messages contain a protocol discriminator that identifies each unique message with a call reference value and a message type. The H.225.0 layer specifies how these Q.931 messages are received and processed.

H.245. The H.245 standard provides the call control mechanism that enables H.323-compatible terminals to connect to each other. H.245 provides a standard means for establishing audio and video connections—the language or steps (series of commands and requests) that must be followed for one component to connect and communicate with another. Specifically, this standard specifies the signaling, flow control, and channeling for messages, requests, and commands.

The built-in framework of H.245 enables codec selection and capability negotiation within H.323. Bit rate, frame rate, picture format, and algorithm choices are some of the elements negotiated by H.245.

Audio and Video Codecs

Codecs define the format of audio and video information and represent how audio and video are compressed and transmitted over the network. H.323 provides a variety of options for audio and video coding. Two codecs, G.711 for audio and H.261 for video, are required by the H.323 specification. H.323 terminals must be able to send and receive ITU-T A-law and µ-law (also known as G.711). Additional audio and video codecs provide a variety of standard bit rate, delay, and quality options that are suitable for a range of network selections. H.323 also enables products to negotiate nonstandard audio and video codecs.

The following paragraphs describe the required audio and video codecs (G.711 and H.261), as well as the two default codecs preferred for NetMeeting connections. G.723 and H.263 offer the low-bit rate connections necessary for audio and video transmission over the Internet.

G.711. The G.711 codec transmits audio at 48, 56, and 64 kbps. This high-bit-rate codec is appropriate for audio over higher speed connections.

G.723. The G.723 audio codec specifies the format and algorithm used to send and receive voice communications over the network. G.723 transmits audio at 5.3 and 6.3 kbps, which is superior for Internet telephony over low-bit-rate connections.

H.261. The H.261 codec transmits video images at 64 kbps (VHS quality). This high-bit-rate codec is appropriate for video over higher speed connections.

H.263. The H.263 video codec specifies the format and algorithm used to send and receive video images over the network. This codec supports CIF, QCIF, and SQCIF picture formats and is superior for Internet transmission over low-bit-rate connections, such as a 28.8 kbps modem.

T.120 Data Communications

H.323 makes a provision for using T.120 as the mechanism for packaging and sending data. T.120 can take advantage of the H.225.0 layer to send and receive data packets, or simply create an association with the H.323 session and use its own transport capabilities to transmit data directly to the network. Support for T.120 enables data from conferencing applications, such as file transfer and application sharing, to operate in conjunction with H.323 connections. Also, this provision enables H.323-compatible products to interoperate with data conferencing products developed under the T.120 specification.

H.323 MCUs, Gateways, and Gatekeepers

The previous section described the H.323 terminal architecture, which NetMeeting supports. The following paragraphs describe other components that can be implemented using the H.323 architecture.

MCUs. The H.323 MCU, also called a conferencing server or conferencing bridge, enables three or more H.323 terminals to connect and participate in a multipoint conference. MCUs include both multipoint controllers, which manage the H.323 terminal functions and capabilities in a multipoint conference, and multipoint processors, which process the audio, video, and data streams between H.323 terminals.

Gateways. H.323 conference gateways enable H.323 terminals on a LAN to connect to H.323 terminals on wide area networks (WANs) or another H.323 gateway. The gateway is the translation mechanism for call signaling, data transmission, and audio and video transcoding. Gateways satisfy part of the interoperability vision of H.32x products—that they can connect to each other.

Gateways can serve one of several purposes:

• To bridge an H.323 call to another type of call, such as a telephone; potentially, NetMeeting could call any telephone around the world 

• To bridge H.323 calls to H.320 (audio and video over ISDN) or H.324 calls (audio and video over POTS standard telephone line) 

• To bridge different networks; an organization could put a bridge on a firewall to connect an internal corporate network with external networks to accept incoming calls.

In this case, the gateway function is similar to an MCU for connecting people over networks. Typically though, the gateway is the translation mechanism in a point-to-point connection, where only one endpoint is an H.323 device. On the other hand, an MCU typically connects many H.323 devices in a multipoint conference.

Gatekeepers. A gatekeeper is an entity that lives on a network and controls H.323 connections. An H.323 device registers with the gatekeeper to send and receive H.323 calls. The gatekeeper is the higher level entity that controls access to the LAN by H.323 terminals, MCUs, and gateways. The gatekeeper gives permission to make a call or accept a call based on a variety of factors, including bandwidth.

A gatekeeper is intended to perform the following functions:

• Controls the number and type of connections allowed across the gateway 

• Limits the amount of bandwidth that connections can use during a call 

• Determines the network address for incoming calls and maintains this information 

Note Gatekeepers are not supported by NetMeeting. For information on how to restrict bandwidth usage by NetMeeting clients, see Chapter 5, "System Policies."

How NetMeeting Uses the H.323 Standard

Microsoft developed NetMeeting audio and video conferencing features based on the H.323 infrastructure, enabling NetMeeting to interoperate with other H.323 standards-based products. H.323 codecs and protocols are the building blocks for these NetMeeting functions:

• The ability to establish and maintain audio and video connections. Two participants can establish a NetMeeting conference with audio and video over a TCP/IP connection. H.225.0 enables multiple audio and video streams to transport inbound and outbound NetMeeting information. H.323 protocols enable NetMeeting to communicate with and transmit data to other compatible audio or video clients. Also, conferencing servers and bridges enable multiuser audio and video conferences between multiple NetMeeting clients, as well as other H.323-compatible products.

• Audio and video codecs that optimize Internet connections. NetMeeting supports a suite of codecs operating between 4.8 kbps and 64 kbps that support various computer and connection types. For optimal performance over the Internet, NetMeeting specifies H.263 and G.723 as the default codecs. NetMeeting may negotiate other codecs, such as H.261 or G.711, depending on the requirements of other H.323-compatible products; these codecs, though, are not used in the vast majority of Internet scenarios (they are used only if a node other than NetMeeting requires it.) Also, NetMeeting creates appropriate payload formats and handlers for custom codecs. 

• Support for T.120 data communications. NetMeeting creates the association between T.120 and H.323 during a NetMeeting conference. This association allows the NetMeeting call to be completed in two phases, one for T.120 and H.323, but appear as a single call. 

• Support for H.323 Gateways. Although Microsoft does not provide a gateway, NetMeeting will support third-party H.323 gateways when they become available. See "H.323 MCUS, Gateways, and Gatekeepers" in this chapter. 

• Support for H.323 Gatekeepers. NetMeeting does not support H.323 gatekeepers. Instead, NetMeeting uses system policies, NT Domain Control, and LDAP-based directories to perform the same functions as the gatekeeper. This enables customers to leverage their investments on other standards-based management tools. 

The standards groups that define H.323 are now working on the next generation of the protocols, and Microsoft is very active in these efforts. The H.323 group is incorporating their experience from the first generation of H.323, and is also adding new features, such as strong security and interoperability with streaming media servers.

Lightweight Directory Access Protocol (LDAP)

The following section contains information about the LDAP standard, its architecture, and how NetMeeting supports LDAP for its Internet Locator Server (ILS) directory services. You can also gain an understanding of LDAP server functions and capabilities.

What is the LDAP Standard?

The Lightweight Directory Access Protocol, as its name implies, is a standard method for application clients to query and access information stored on directory servers over TCP/IP connections. Typically, a published directory contains data about people or other entities that users can access. The most common examples of paper-based directories are the yellow and white pages of telephone books, which enable a customer to look up the telephone number for a person or company. An example of an electronic directory is a published e-mail address book, which enables an e-mail user to look up a person's e-mail address and other details, such as office location and internal phone extension.

LDAP is derived from the X.500 global directory and the Directory Access Protocol (DAP), a complex access protocol for performing a wide variety of directory functions. LDAP is a lightweight offspring of DAP, shedding the unnecessary features of client-server access scenarios. The result of the weight loss is LDAP, a protocol that greatly simplifies implementation, reduces software complexity, improves performance, and in the process, encourages wider adoption.

LDAP Version 2 and Version 3

Most Internet applications currently support LDAP Version 2, which provides static directory services for storing user information that is constant. Traditionally, directories contain data that rarely changes. Telephone books are published once a year because customers do not change numbers frequently. E-mail directories are also very stable, typically requiring changes only when new users are added or outdated users are removed. One result is that a directory is read very often but seldom written.

LDAP Version 3 is currently being developed. This version includes specifications for dynamic directory services, which store user information that changes frequently. Dynamic information can expire and must be refreshed periodically to remain up to date (for example, IP addresses through the dynamic host configuration protocol). Ratification of this new version is expected in the near future.

Benefits

LDAP has several benefits that give this standard an advantage over other directory server protocols:

• With LDAP, Internet clients, servers, and applications have a common method for accessing and utilizing directory information. 

• LDAP provides a simple search operation that reduces the amount of input and output processing. This is important for Internet implementations that favor more simplistic processing methods for slow Internet connections. 

• By using TCP/IP connections, LDAP can be implemented relatively easily on most platforms. 

• Directory servers developed under LDAP can support many users and their associated address information. 

• With dynamic directory services, LDAP can track more volatile information that changes frequently and must be refreshed on a regular basis. This is a requirement for dynamic call directories that need to be continually refreshed to show the most current directory of users. 

Interoperability

Many current servers use LDAP Version 2 technology, and developers can easily create new servers that provide dynamic directory services (required for NetMeeting). For more information about LDAP interoperability, see Chapter 9, "Product Interoperability" and also "Developing Compatible Servers" later in this chapter.

LDAP Architecture

The IETF Web site documents the LDAP architecture. For detailed information, visit https://www.ietf.org/ids.by.wg/ldapbis.html  . The following diagram illustrates the LDAP architecture. LDAP clients, such as e-mail programs, Web browsers, and external applications, can execute directory service transactions against the LDAP server. Directory services define the operations for locating and connecting people who want to join a conference. This capability may include simple search and update transactions, such as logging on and off, creating a directory listing of all available users, and resolving a user's address information.

Through an LDAP interface, the server communicates with the LDAP database to retrieve directory information. LDAP servers can be multi-threaded to support many LDAP databases simultaneously. The LDAP database stores and retrieves information based on a hierarchical structure of entries, each with its own distinguishing name, type, and attributes. The attributes (properties) define acceptable values for the entry. An LDAP database can store and maintain entries for a large number of users.

Databases can include static entries, dynamic entries, or both. A static entry contains information that will be accurate for a long period of time. On the other hand, dynamic entries (objects) and their attributes have a defined life expectancy and will expire if they are not refreshed by the client. The LDAP server is responsible for removing expired entries.

How NetMeeting Uses the LDAP Standard

Traditional static directories contain information that is presumed to have value until it is removed. In contrast, NetMeeting's directory information quickly degrades over time. Because NetMeeting is an IP-based conferencing application, the most important attribute is the computer's network or IP address. With the widespread use of DHCP, each time a user logs on to a LAN or ISP, their machine is assigned a different IP address, which means that the directory information needs to be frequently updated. Therefore, a traditional static database approach to write seldom and read often cannot be used.

NetMeeting directory requirements resulted in the Microsoft ILS, a new breed of LDAP-based dynamic directory services. ILS information can be updated as frequently as desired because storage is not based on SQL or file-based databases; instead, the ILS stores directory data in memory to allow frequent changes. Even though the directory stores information differently, access to the information is still the same as traditional static directories. Therefore, NetMeeting uses the LDAP protocol to access the ILS.

NetMeeting and the ILS support the LDAP standard for the following functions and capabilities:

• Using the LDAP Client-Server Infrastructure. Based on the LDAP infrastructure, the ILS consists of both a client and a server. NetMeeting uses the client to access the server through an LDAP interface. The ILS provides a publishing mechanism that enables NetMeeting to publish information about its users for other people to view and search. For example, if NetMeeting publishes a user's name, online status, and audio/video capability, a potential caller can then identify the party to call, whether the user has video capability, and whether the user is currently in a call.

• Support for Dynamic Objects (LDAP Version 3). The ILS defines two dynamic object types: the User object and MeetingPlace object. The User object defines the properties of a NetMeeting user and is used to publish information about that user. The MeetingPlace object defines the properties of an ongoing conference. Each object consists of attributes, or properties. For example, the User object includes attributes, such as "First Name" and "Country," and the MeetingPlace object includes attributes, such as "Attendee" and "Description." 

  The ILS client provides a number of operations for publishing each object:

  Registration: Allows an object to be published on an ILS. 

  Unregistration: Unregisters or removes a registered object. 

  Refresh: Refreshes a registered object so that it will not be deleted. 

  Resolve: Given a unique name, returns the entire object matching that name. 

  Enumeration/Query: Given a particular set of criteria, returns all matching registered entries; for example, this operation could return all User objects matching the criteria "Last Name" equals "Smith." 

  Modify: Modifies attributes of an object. 

• Dynamic Entry Expiration and Refresh Operations. An important concept for dynamic directories is entry lifetime—each entry is valid only as long as the NetMeeting client is active. If the client computer goes offline (for example, the computer connection is terminated by another incoming call) the ILS entry is no longer valid, and will be removed by the server as soon as possible. Each NetMeeting entry in the ILS directory has a lifetime, which is typically a specific number of minutes. NetMeeting regularly refreshes its entries in the ILS, maintaining only those entries that are still online and ready to accept a call. If a NetMeeting entry fails to refresh itself within the allotted time, the server removes the entry to keep the entire directory listing as accurate as possible. 

  NetMeeting and ILS 1.0 use LDAP Version 2, the most current, approved version of the LDAP specification. However, the concept of dynamic entry lifetime and refresh are not defined in LDAP Version 2. In LDAP Version 3, Microsoft, in conjunction with other IETF members, have proposed standard operations in the LDAP protocol to define object lifetime and refresh. This proposal for dynamic entries is currently undergoing review, and agreement on Version 3 is expected in the near future. Therefore, the next version of NetMeeting and the ILS should incorporate the migration to LDAP Version 3. 

• Developing Compatible Servers. As described in this section, NetMeeting's unique capabilities impose new requirements for LDAP-based directory services that are unique to real-time conferencing applications. The ILS provides new services that were previously unavailable with LDAP Version 2. Because of this innovation, no other compatible servers are currently available for NetMeeting.

Compatible server products, though, can be engineered without a high development learning curve. The ILS uses the well-known industry standard LDAP for its access protocol, and these servers are close cousins of traditional static LDAP servers. ILS functionality and transactions are open and published; therefore, expertise in developing traditional LDAP directories can be easily applied toward building ILS-like directories. Because LDAP is the standard for directory protocols, any infrastructure or tools, such as proxy servers, firewall, or networking monitoring tools, are completely applicable with it. Also, the ILS can easily be integrated with static directories that use a common LDAP protocol.