The International Telecommunications Union (ITU) is a UN body which establishes communications standards that form the foundation for many of the interoperable communications that we all take for granted. Probably the set of standards which most readers are most familiar are the V.XX series of recommendations which cover virtually all the modems and fax machines in use today.

In 1990, the ITU adopted H.320 which sets standards for audio video telephony over switched digital networks, particularly ISDN. H.320 has become virtually a requirement in both the desktop and group system videoconferencing markets. In 1996, the ITU adopted H.323, another umbrella recommendation which sets standards for voice, video, and data communications over IP networks. H.323 is intended for corporate LAN environments, but because of its IP foundations, has direct application to the Internet and corporate Intranets. A summary chart of the ITU recommendations affecting videoconferencing is given at the end of this article.

Hence, H.323 creates a crucial foundation for interoperability across a wide range of multimedia products and applications from multiple vendors. H.323 should be a keystone of your product plans whether you are involved in consumer, business, entertainment, or professional applications. Because H.323 operates over a wide range of network bandwidths and is independent of host architecture, H.323 will be implemented on workstations, PCs, network computers, and stand-alone devices in a variety of DSP-assisted and host-reliant configurations. Already H.323 software products are hitting the market intended for OEM licensees, and according to a recently released research report by Forward Concepts (Tempe, AZ), H.323 capability is likely to be embedded in many platforms and operating systems before the end of the decade.

Technically speaking, H.323 is an umbrella recommendation from the International Telecommunications Union (ITU) that sets standards for multimedia communications over Local Area Networks (LANs) which do not provide a guaranteed Quality of Service (QoS). These non-guaranteed QoS networks dominate today's corporate desktops and include packet-switched TCP/IP, IPX, Ethernet, Fast Ethernet, and Token Ring network technologies. Hence, the H.323 standards are important building blocks for a very broad, new range of collaborative, LAN-based applications voice, video, and data communications:

• Collaborative computing 
• Interactive gaming 
• Business conference calling 
• Desktop videoconferencing 
• Interactive shopping 
• Internet telephony and videotelephony 
• Remote presentations. 

In short, H.323 specifies how interactive audio, video, and data communications occur in a networked environment. While H.323 covers a wide range of options, only voice communications is actually required; the other media are optional. However, H.323 does specify how all media are to be handled, if they are supported by a device.

Because H.323 deals with both compression/decompression standards (for audio and video) and the complexities of today's LAN architectures, the Recommendation is somewhat longer and more complicated than other recommendations in the H.32X series. New functionality in H.323 specifies how Gatekeepers can provide address translation and bandwidth management and how Gateways can connect LAN and WAN terminals This primer presents the fundamental issues incorporated in H.323 in order to provide you with an overview of the Recommendation, its benefits, technologies, and applications.

Why is H.323 Important?

H.323 covers voice, video, and data communications over the LAN architecture connecting tens of millions of endpoints. The Recommendation is comprehensive, while being flexible and includes configurations from voice-only headsets, to voice and video games, to full multimedia videoconferencing stations. H.323 and LAN-based applications are about to burst into the mainstream market for six reasons.

1. H.323 sets standards for multimedia traffic across IP-based networks, the mainstream of the corporate world and the foundation protocol for the Internet. Standards are crucial for device-to-device, application-to-application, and vendor-to-vendor interoperability. H.323 is designed to compensate for the effect of highly variable LAN latency on isochronous voice and video data.

2. LANs are already installed in most corporate environments. H.323 sets multimedia standards for the existing infrastructure. No new wiring to enable multimedia communications.

3. IP LANs are becoming more powerful as 10 Mbps Ethernet moves from a shared to a switched technology, and the raw bandwidth of Ethernet itself migrates from 10 Mbps to 100 Mbps. Gigabit Ethernet is already on the horizon.

4. PCs are becoming more powerful multimedia machines due to faster clock rates, enhanced instruction sets, and powerful multimedia accelerator chips.

5. H.323 provides standards for LAN conferencing as well as standards for LAN-WAN interoperability, a key concern of conferencing users.

6. H.323 addresses a major concern of network managers: bandwidth hogging. The Recommendation defines a role for Gatekeepers which will keep video traffic from eating up all available bandwidth. 

Key Benefits of H.323

• CODEC Standards
H.323 establishes standards for compression/decompression of audio and video data streams as well as standards for multiplexing of data streams, call set-up, and call tear down. By adhering to standards, vendors will ensure that their equipment will work with that from other vendors.
• Vendor-to-Vendor Interoperability
Users want to "make the call" without having to worry about whether the receiving equipment is from the "right" manufacturer or will be able to handle the data. Beside ensuring that data is compressed in a way that a receiver can decompress it, H.323 establishes methods for receiving terminal equipment to communicate its capabilities to the sender equipment.
• Network Independence
H.323 is designed to ride on top of common network architectures, including CS/CDMA and Token Ring. As network technology evolves, as bandwidth and bandwidth management techniques improve, H.323-based solutions will take be able to take advantage of the enhanced capabilities.
• Inter-Network Conferencing
While conferencing with a LAN environment will enhance collaborative computing, many users want to be able to conference from the LAN to a remote site. H.323 establishes the role of the Gateway and the standards by which the Gateway will connect H.323 LAN-based systems to each other over the WAN, or to a remote Terminal connected directly to the WAN. H.323 uses common CODEC technology from different videoconferencing standards in order to minimize transcoding delays and to provide optimum performance in an inter-network connection.
• Bandwidth Management
Video and audio traffic is bandwidth intensive and has the capability of bringing the corporate data LAN to its knees. H.323 addresses this issue with the Gatekeeper, a device which gives LAN managers the assurance they need that H.323 bandwidth allocation is reasonable and that mission critical data traffic will continue to function properly.
• Platform and Application Independence
H.323 is not tied to any hardware or operating system. H.323-compliant platforms will be available in many sizes and shapes, including video-enabled personal computers, dedicated platforms, and turnkey boxes.
• Multipoint Support
One of the values of any conferencing system is the ability to support multi-point communications. The ability to support multicasts in software is a major advantage of LAN-based conferencing over circuit-switched connections. Multicasting allows a single packet to be received by a selected subset of destinations on the network. This is in contrast to unicasting, which sends data to one receiver, and broadcasting, which sends data to all receivers. LAN-based multicasts economize bandwidth, since all stations in the multicast group read a single data stream.
• Flexibility
An H.323-compliant device must support voice. Data and video support are options. Furthermore, an H.323 multimedia terminal can share the data portion of a video conference with a T.120 data-only terminal, while sharing voice, video, and data with other H.323 terminals. 

H.323 Architectural Overview

Recommendation H.323 covers the technical requirements for narrow-band visual telephone services in those situations where the transmission path includes one or more local area networks (LANs) which may not provide a guaranteed Quality of Service (QoS). A companion ITU Recommendation H.322 covers LANs which do provide a guaranteed QoS. The scope of H.323 does not include the LAN itself, or the transport layer which may be used to connect various LANs. Only elements needed for interaction with the Switched Circuit Network (SCN) are within the scope of H.323.

H.323 defines four major components for a network-based conferencing system: terminals, gateways, gatekeepers, and multipoint control units.

Terminals

These are the client endpoints on the LAN which provide for real-time, two-way communications. Most H.323 terminals in the near future will be desktop computers running H.323 software. All terminals must support voice communications, hence H.323 will be the dominant foundation of the next generation of Internet phones, audioconferencing terminals, and remote presentation technologies. Support for video and data are options. Therefore H.320 terminals will be available with a range of media support. However, if audio, video, or data are indeed supported, then H.323 specifies what modes of operation are required so that all terminals supporting that media type can interwork.

Figure 1: Scope of Recommendation H.323

All H.323 terminals must also support Recommendation H.245, which is needed for negotiating channel usage and capabilities. Because H.245 is extremely complex and covers a number of options, several companies have joined together with the IMTC to define what is known as H.245 Profile 1, a scaled-down implementation. Also required for a terminal is support for part of Recommendation H.225, namely a scaled-down version of the Q.931 component which is used for call signaling and call setup, and support for RTP/ RTCP for sequencing audio and video packets.

H.323 terminal options include support for video CODECs, the T.120 data protocols, MCU capabilities (described further below), and an H.225 component called RAS (Registration/Admission/Status) which is a protocol used to communicate with a Gatekeeper.

Gateways

These devices provide many services, including the needed translation function between H.323 conferencing endpoints on the LAN and other ITU-compliant terminals on other ITU-compliant circuit-switched and packet-switched networks. These services include translation between transmission formats (for example H.225.0 to H.221) and between communications procedures (for example H.245 to H.242). In addition, the Gateway also does the translation between audio and video CODECs if this is needed as well as performs call setup and clearing on both the LAN side and the SCN side.

In general, the purpose of the Gateway (when not operating as an MCU) is to reflect the characteristics of a LAN endpoint to an SCN endpoint, and vice versa. The primary applications of Gateways are likely to be:

• Establishing links with remote H.320-compliant terminals over ISDN-based switched circuit networks. 
• Establishing links with remote H.324 compliant terminals over POTS-based switched circuit networks. 
• Using the WAN to connect H.323 terminals on one LAN with H.323 terminals on another LAN. 

Figure 2: H.323/H.320 gateway technology

Gateways are not required if LAN-WAN connections are not needed, since endpoints may communicate with other endpoints on the same LAN directly. It is feasible however for a terminal on one segment of the LAN to call out through one Gateway and back onto the LAN through another Gateway in order to bypass a router or a low bandwidth link. Equipment which provides transparent interconnection between LANs, such as routers and remote dial-in access units, are not Gateways as defined within H.323.

Gateways also can perform multipoint control functions. In some situations a Gateway may operate initially as a terminal, but later use H.245 signaling to begin to operate as an MCU for the same all that was initially point-to-point. Gatekeepers are aware of which terminals are Gateways since this is indicated when the device registers with the Gatekeeper. Also, a Gateway may contain a T.120 MCS Provider which connects the T.120 MCS Providers on the LAN to the T.120 MCS Providers on the SCN. If a Gateway includes an MCU function on the LAN side, then the Gateway should appear as an H.323 MCU. But the Gateway can also perform MCU functions on the SCN side, in which case it appears as an H.231/H.243 MCU, or as an MCU for H.310 or H.324 systems as defined in other ITU Recommendations.

ITU terminals supported by H.323 Gateways include those complying with H.310, H.321, H.322, and V.70 (DSVD). Many capabilities of Gateways are left to the designer. For example, the actual number of H.323 terminals that can communicate through the Gateway is not subject to standardization. Similarly, the number of SCN connections, number of simultaneous independent conferences supported, the audio/video/data conversion functions, and inclusion of multipoint functions are left to the manufacturer. But, by incorporating Gateway technology into the H.323 specification, the ITU has positioned H.323 as the glue to hold together the world of standards-based conferencing endpoints.

Pic.3

Gatekeepers

Gatekeepers perform two important call control housekeeping chores which help preserve the integrity of the corporate data network. The first is address translation services between LAN aliases for terminals and gateways and IP or IPX addresses. The second Gatekeeper function is bandwidth management. For instance, if a LAN manager-specified threshold for the number of simultaneous conferences on the LAN has been reached, the Gatekeeper can refuse to make any more connections. The effect is to limit the total number of conferencing bits/s to some fraction of the total available; the remainder are left for email, file transfers, and other normal store-and-forward data functions. The collection of all Terminals, Gateways, and Multipoint Control Units managed by a single gatekeeper is known as an H.323 Zone.

While a Gatekeeper is logically separate from H.323 endpoints, its physical implementation is likely to be such that the Gatekeeper functions coexist with the terminal, Gateway, and/or MCU functions in the same system.

A Gatekeeper is not required in an H.323 system. However, if a Gatekeeper is present, mandatory services include:

Optional Gatekeeper functions defined within H.323 include:

Gatekeepers also play a role in multipoint connections. In order to support Ad Hoc Multipoint Conferences, users would employ a Gatekeeper to receive H.245 Control Channels from two terminals in a point-to-point conference; when the conference switches to a multipoint conference, the Gatekeeper can redirect the H.245 Control Channel to an MC. The Gatekeeper need not process the H.245 signaling, it only needs to pass it between the terminals or the terminals and the MC.

LANs which contain Gateways should also contain a Gatekeeper in order to translate incoming E.164 addresses into Transport Addresses. Because a Zone is defined by its Gatekeeper, H.323 entities that contain an internal Gatekeeper require a mechanism to disable the internal function so that when there are multiple H.323 entities that contain a Gatekeeper on a LAN, the entities can be configured into the same Zone.

Pic.4

Multipoint Controller Units (MCU)

The multipoint controller, which supports conferences between three or more endpoints, is a very flexible capability in H.323 systems. Under H.323, an MCU consists of a Multipoint Controller (MC), which is a required component, and zero or more Multipoint Processors (MP). The MC handles H.245 negotiations between all terminals to determine common capabilities and controls conference resources such as multicasting. The MC does not deal directly with any of the media streams. This is left to the MP, which does the mixing, switching, and other processing of audio, video, and/or data bits. MC and MP capabilities can exist in dedicated hardware resources, or coexist in other H.323 elements.

H.323 Multipoint Conferences

Multipoint conference capabilities are handled in a variety of methods and configurations under H.323. The Recommendation uses the concepts of centralized and decentralized conferences.

Centralized multipoint conferences require the existence of an MCU to facilitate a multipoint conference. All terminals send audio, video, data, and control streams to the MCU in a point-to-point fashion. The MC centrally manages the conference using H.245 control functions which also define the capabilities for each terminal; the MP does the audio mixing, data distribution, and video switching/mixing functions typically performed in multipoint conferences and sends the results back to the participating terminals. The capability set by the MC for a terminal is known as the Selected Communication Mode (SCM) for the conference. The MP may also provide conversion between different CODECs and bitrates, and may use multicast to distribute processed video. Hence a typical MCU that supports centralized multipoint conferences consists of an MC and an audio, video, and data MP.

Decentralized multipoint conferences makes use of multicasting technology. Hence a typical MCU that supports decentralized multipoint conferences consists of an MC and a data MP supporting T.120. Participating H.232 terminals multicast their audio and video to other participating terminals without using an MCU. Note that multipoint data conferences are still centrally processed by an MP and that H.245 Control Channel information is still transmitted in a point-to-point mode to an MC. Receiving terminals are responsible for processing the multiple incoming audio and video streams themselves. Terminals use H.245 Control Channels to indicate to an MC managing the conference how many simultaneous video and audio streams they can decode. The number of simultaneous capabilities of one terminal do not limit the number of video or audio streams which are multicast in a conference. The MC may also provide management functions such as chair control, video broadcast, and video selection using H.245 signaling.

H.323 also supports mixed multipoint conferences, in which some terminals are in a centralized conference, others are in a decentralized conference, and an MCU provides the bridge between the two types. A terminal is not aware of the mixed nature of the conference, only of the type of conference in which it is participating.

By supporting both multicasting and unicasting approaches, H.323 spans current generation and future networking technologies. For networks which are multicast-enabled, users can define group IP addresses and send a common video feed to the group. (Multicasting of audio is not covered in the initial release of H.323.) Network resources will replicate the data where it is necessary. Multicasting makes more efficient use of network bandwidth, but places higher computational loads on the terminals, who have to mix and switch their own audio/video receiving streams.

A current limit of H.323 is imposed by the architecture of one MC per multipoint conference. While the theoretical limit this imposes is quite large, the practical limits of H.323 conferencing are such that most users will find more than 10-20 participants per conference to be unsatisfactory. Market research indicates that the vast majority of multipoint conferences to date, which admittedly take place over the WAN and not the LAN, are with eight participants or fewer.

The H.323 definition of multipoint control units is very flexible. An MC may be located within a Gatekeeper, Gateway, Terminal, or MCU.
Consider a simple example where a multipoint conference is set up between three clients. One client terminal (Terminal 1) performs the MC function. All the terminals could use multicasting (a decentralized conference). An MP function would have to execute on each node to mix and present to the user the audio and video signals. While this approach minimizes the number of hardware resources, each of the clients needs additional CPU power. And the network must be configured to support multicasting. In addition, it could be difficult to bring in another participant during the conference. Alternatively, a separate MCU may be used to handle only the data or control functions. In this configuration the video may still be multicast, conserving bandwidth.

If this example were shifted to a centralized conference, then one node would have to act as an MCU. This MCU could be either a dedicated system (MCU 1 or MCU 2), or a terminal with extra horsepower. One advantage of centralized conferencing is that all H.323 terminals support point-to-point communications. In one case, the MCU may output multiple unicasts to the conference participants and no special network capabilities are required. In a different case, the MCU could receive multiple unicasts, mix audio and switch video, but output a multicast stream, conserving network bandwidth.

Multipoint conferences that span terminals on both the LAN and WAN are likely to benefit from configurations where the MCU functions are tightly integrated with the Gateway.


Audio, Video, Data, and Control

Communications under H.323 can be considered as a mix of audio, video, data, and control signals. Their interaction is shown in the block diagram of an H.323 terminal. Only audio capabilities and H.225 control and signaling are required; all other capabilities, including video and data conferencing are optional. When multiple algorithms are possible, the algorithms used by the encoder are derived from information passed by the decoder during the capability exchange using H.245. H.323 terminals are also capable of asymmetric operation (different encode and decode algorithms) and may send/receive more than one video and audio channel.

Control

The heart of the H.323 terminal is the system control functions. The System Control Unit provides signaling for call control, capability exchange, signaling of commands and indications, and messages to open and describe the content of logical channels. All audio, video, data, and control signals themselves pass through an H.225.0 layer which formats the data streams into messages for output to the network interface. The reverse process takes place for incoming streams. This H.225.0 layer also performs logical framing, sequence numbering, error detection, and error correction as appropriate to each media type.

Overall system control within H.323 is provided by three separate signaling functions: the H.245 Control Channel, the Call Signaling Channel, and the RAS Channel.

The H.245 Control Channel is a reliable channel which carries control messages governing operation of the H.323 entity, including capabilities exchange, opening and closing of logical channels, preference requests, flow control messages, and general commands and indications. Capabilities exchange is one of the fundamental technologies in the ITU recommendation; H.245 provides for separate receive and transmit capabilities as well as for methods to describe these details to other H.323 terminals. There is only one H.245 Control Channel per call.

The Call Signaling Channel uses H.225.0 to establish a connection between two H.323 endpoints or between a terminal and a Gatekeeper.
The RAS signaling function uses H.225.0 to perform registration, admission, bandwidth changes, status, and disengage procedures between endpoints and Gatekeepers. RAS is not used if a Gatekeeper is not present.

Audio

Audio signals contain digitized and compressed speech. The compression/decompression algorithms supported by H.323 are all proven ITU standards. All H.323 terminals must support G.711 speech compression. Support for the other ITU voice standards is optional. The different ITU recommendations for digitizing and compressing speech signals reflect different tradeoffs between speech quality, bit rate, computer power required, and signal delay. G.711 generally transmits voice at 56 or 64 kbps, well within the bandwidth limits likely on a LAN, but was designed originally for continuous bit-rate networks. An H.323 terminal would need to support G.723, however, for H.324 connectivity. G.723 operates at very low bit rates. G.729 is a low delay, low-bitrate CODEC used in V.70 DSVD modems. G.729 requires less computer horsepower than G.723, which may be important if voice coding is left to the H.323 terminal. G.729 is also better designed to withstand packet loss.

Video

While video capabilities are optional, any video-enabled H.323 terminal must support the H.261 CODEC; support for H.263 video is optional. Video data is transmitted at a rate no greater than that selected during the capability exchange. H.261, which provides a measure of compatibility across many of the different ITU recommendations (see table below), is for use with communication channels that are multiples of 64 kbps (P=1,2,3...30.). H.261 calls for fully-encoding some frames and for coding only the difference between a frame and the previous frame in other cases. Motion compensation, which improves image quality, is an H.261 option.

H.263 can be considered a backward compatible, five-year update to H.261. H.263 picture quality is greatly improved by using a required 1/2 pixel motion estimation technique, predicted frames, and a Huffman coding table optimized for low bit rate transmissions. H.263 defines five standardized picture formats. Communications between H.261 systems and H.263 systems is facilitated because both must support QCIF.

Table 4: ITU image formats for videoconferencing

Data

Data conferencing (still pictures, facsimile, documents, computer files, etc.) is an optional capability. H.323 handles data by incorporating the T.120 series of communication and application protocols that provide support for real-time, multipoint data communications.

IP Networking and Multimedia Conferencing

H.323 uses the concepts of both reliable (or confirmed) and unreliable (unconfirmed) communications. Reliable transmission of messages uses a connection-mode for data transmission. In the IP stack, this is accomplished with TCP. Reliable transmission guarantees sequenced, error-free, flow-controlled transmission of packets, but at the cost of delayed transmission and reduced transmission throughput. H.323 uses reliable (TCP) end-to-end services for the H.245 Control Channel, the T.120 Data Channels, and the Call Signaling Channel.

The alternative to TCP is UDP, which, since it is optimized for efficiency, provides minimal control information and is considered an unreliable service. Unreliable transmission is a connectionless-mode technique which promises nothing more than "best effort" delivery. H.323 uses UDP for the audio, video and the RAS Channel. These services themselves may be duplex or simplex, unicast or multicast, since UDP supports multicasting. Riding on both TCP and UDP, H.323 can be viewed as a protocol stack, which gives a slightly different view from that of the terminal block diagram.

Pic.5

UDP by itself is not good enough however. H.323 also uses protocols from the Internet Engineering Task Force (IETF) designed to handle streaming audio and video. The Real-time Transport Protocol (RTP) allows applications to compensate for the unreliability of UDP. RTP tacks onto each UDP packet a 10-byte header containing a timestamp and a sequence number. With appropriate buffering at the receiving station, timing and sequence information allows the videoconferencing application to eliminate duplicate packets, reorder out-of-order ones, synchronize sound, video and data, and achieve continuous playback in spite of varying latencies. Because H.323 is RTP-based, it's also well-suited to the Internet's Multicast Backbone (Mbone), a virtual network on "top" of the Internet providing a multicasting facility, and supporting video, voice and data conferencing. Mbone applications typically use RTP.

Pic.6

The real-time transport control protocol (RTCP) is used for the control of RTP. RTCP monitors the quality of service, conveys information about the session participants, and periodically distributes control packets containing quality information to all session participants through the same distribution mechanisms as for the data packets.

Having sufficient bandwidth for a multimedia call is critical and difficult to ensure in large packet networks like the Internet or a company Intranet. Another IETF protocol, the Resource ReSerVation Protocol (RSVP) allows a receiver to request a specific amount of bandwidth for a particular data stream and receive a reply indicating whether the request has been granted or not. Although RSVP is NOT an official part of the H.323 standard, most H.323 products should support it, because bandwidth reservation is critical to the success of video conferencing on LANs. RSVP is initiated by receiver terminals, not sender terminals. While RTP only has to be supported by end points (terminals), RSVP needs to be supported by intermediate switches or routers. If any device in the conferencing data path doesn't support RSVP, it can be a bottleneck.

Overview of ITU Videoconferencing Standards

H.323 is the newest member of a family of ITU umbrella recommendations which cover videotelephony and multimedia communications over a variety of pipelines. H.323 is in many senses a derivative of H.320, a 1990 umbrella recommendation for videotelephony over switched digital telephone networks. H.323 borrows heavily from H.320's structure, modularity, and audio/video CODEC recommendations.

Table 5: The ITU Umbrella Recommendations for Transmission of Non-Telephone Signals. * H.263 rev 2 is under study

Interoperability

Many ITU Recommendations are complex, and certain areas are subject to interpretation by product designers. In addition, many topics covered by the Recommendations are required functionality, while others are optional. In the past few years, interoperability testing has come to the forefront, sponsored by the International Multimedia Teleconferencing Consortium (IMTC) and supported by the National Institute for Standards and Technology (NIST) and dozens of individual hardware and software companies. So, while the ITU's role is that of a standards-setting body, the IMTC focuses on the practical validation and promotion of standards. The IMTC's emphasis is on Multimedia Teleconferencing, including still-image graphics, full motion video and data teleconferencing. It is focused on ensuring the adoption of the required standards and education of the market.
IMTC-organized events are intended to facilitate the rapid development and delivery of standards-based conferencing products and services and to continue promoting the importance of industry-wide interoperability as a base for building consumer confidence. To date, the interoperability tests have centered on H.324 testing and T.120 testing in a variety of POTS and ISDN-based endpoint-to-endpoint and multipoint network configurations. H.323 interoperability tests will undoubtedly begin during 1997 and extend over a protracted period of time as multiple vendors cooperate to test a multi-dimensional matrix of equipment, networks, CODECs, and protocols.

Implementing H.323

For many OEMs, the rapid rate of change in computers, electronics, and communications is causing them to analyze any product as a series of value-added technology layers. Keeping up with any layer is a challenge; keeping on top of the whole audio, video, graphics, imaging, and telephony stack is near impossible. How can OEMs keep on top of the technology turmoil while developing new products inside ever smaller windows of market opportunity? Managers need to look at each product layer and re-evaluate make-vs.-buy decisions. Here are a few of the issues to ponder:

• If a part or subsystem is a commodity, it is often uneconomical to design and build a custom version. Similarly, if the part or software is complex, but available, it is often more prudent to buy rather than build. 
• Being 6 months late to market can cost a company 50% of the profits in a product life cycle. 
• Complexity and high rates of change put more economic value on specialization, and less value on vertical integration. 
• Today's OEM needs to understand where his valued-added lies (user interface, distribution channels, system integration, technical support, hardware design, and so on), which development activities maximize his returns, and which tasks and technologies are better left to "buy" decisions.