Document Managed by Network Operations

Purpose

This document provides general information on the relevant H.323 standards governing voice and video applications on data networks; identifies criteria for the selection, configuration and use of H.323 encoding devices; lists industry accepted best practices for effective application operation; and defines a reference model for the implementation H.323 compliant video conferencing for use on RUNet. It is intended for use by university technical staff responsible for the management and operation of IP video infrastructure.

Video Protocols

The International Telecommunications Union (ITU) has created the H.323 standard as an umbrella specification governing the use of voice and video protocols on data networks. The standard incorporates the ITU specifications and standards for voice and video network call access control, call setup (H.225), call control signaling (H.245), additional bearer capabilities, resource allocation, in-call signaling and call termination. The H.323 standard applies these generalized standards for circuit-switched networks to packet-switched data networks.

The diagram below shows the family of protocols that comprise H.323, their function, and where their interaction with other protocols defined in the Open Systems Interconnection (OSI) model.

H.323 compliant implementations are intended to operate smoothly between equipment of different manufacturers, but there are known interoperability problems. Conformance with the University video reference model is the best way to avoid video quality problems such as jitter and lost packets while maintaining CODEC interoperability with the standards of NJEdge and Internet2.

Wiring Standards

The data network's physical characteristics must conform to either the Rutgers Telecommunications Infrastructure Specifications for Cabling, or the ANSI/EIATIA-568-B specifications. Briefly, all cables must be rated at least Category 5 or better. Locally made connectors or wiring should not be used unless installed by a BICSI certified technician who is familiar with contemporary industry facilities, and performs appropriate measurements and tests to certify full compliance with published standards.

The Telecommunications Infrastructure Specifications for Cabling are available at: http://www.td.rutgers.edu/documentation/Reference/Telecommunications_Infrastructure_Specifications_Cabling/pdf/index.pdf

Media Access Control

The collision domain of the CODEC must be distinct to ensure that there is no contention for resources at the media layer. A full duplex switch port effectively permits the CODEC interface to be the only device in its respective collision domain. A connection speed of 100Mbit is advised. Half duplex connections are not permitted as they essentially imply that there are two interfaces within the collision domain. The duplex mode and speed on one or both of the CODEC and switch should be set manually. Since this setting is intended to be host specific, it is architecturally best to manually set mode and speed on the CODEC where possible. If the switch fails to establish proper mode and speed after the CODEC is statically configured, mode and speed on the switch should also be statically configured. It is not advisable to allow the CODEC and switch to automatically negotiate speed and duplex given known interoperability issues arising during the autonegotiation process.

The requirement for a dedicated collision domain precludes the use of shared media such as repeaters and hubs anywhere along the video path. Wireless technologies conforming to the 802.11 standards are shared media protocols, and should not be utilized to service H.323 CODECs. The University data network utilizes only routers and switches for all backbone segments and aggregation devices. Local Area Network (LAN) design must utilize similar technologies to ensure a quality video path from end to end.

Internet Protocol

Voice and Video applications generally place high demand on the network's resources. Industry best practices place CODECs in dedicated networks where there is little contention for network resources. It is strongly recommended to isolate CODECs from network devices that rely heavily on broadcast capabilities as such network chatter forces the CODEC to compete for resources. Excessive broadcast traffic may a natural side effect of the network environment, as in some Microsoft network installations, or it may be the result of poor network design or malicious activity. The CODEC should be placed in as small an IP network as feasible in order to minimize the need to compete with other devices and applications for resources, and to minimize the exposure to misconfigurations and other network errors.

Quality of Service

When used properly, Quality of Service (QoS) may provide voice and video application endpoints with more reliable call quality by giving the application's traffic priority over normal network traffic. RUNet endorses the QoS standards set forth by the NJEdge.net consortium. To ensure proper interaction with NJEDge.net compliant devices across the NJEDge.net infrastructure, packets must be appropriately tagged. All data planes (video, audio, control, etc) should be marked with an IP precedence of 4. The Type of Service (TOS) bit should be clear. The Resourced Reservation Protocol (RSVP) should not be enabled, as it is not supported on the NJEdge network.

At this time, RUNet does not provide general support for application specific differentiated service. Pursuant to the NJEdge.net standards for QoS, RUNet devices, in general, will honor QoS markings, but will not provide specialized or priority handling for application traffic. RUNet devices do not currently modify markings in packet headers. University CODECs should have QoS enabled and parameters set as indicated above.

Any future university initiatives associated with differentiated network service will conform to the NJEdge.net standards established by the NJEdge.net consortium.

Hostname Registration

All IP addresses in use by CODECs must have corresponding DNS names within the rutgers.edu domain. Properly registered hostnames simplify the identification of devices for network audit purposes and facilitate contact with the device administrator in the event of an emergency. Additionally, corresponding forward and reverse hostnames are now required by some secure services that CODECs may use. Information on registering Rutgers hosts can be found at the hostmaster website: http://hostmaster.rutgers.edu

For CODECs with ISDN interfaces, registration of your E.164 address with an ENUM registrar is a requirement for certification on the NJEdge network. Please contact your ISDN provider for more information.

Gatekeeper Services

The H.323 standard includes a specialized gatekeeper directory service that is responsible for performing endpoint registration, endpoint authentication, access control, bandwidth management and directory lookup services. The gatekeeper acts as a central authority for a network of H.323 endpoints. All endpoints in the network must register with the gatekeeper to participate in the zone dial plan. OIT centrally manages gatekeeper services for the university community.

The gatekeeper may be located at gk01-hill012-svcs.rutgers.edu, or by IP address at 165.230.252.48.

Multipoint Control Unit

A Multipoint Control Unit (or MCU) can be used to negotiate conference calls between two or more video terminals. MCU's are capable of negotiating and maintaining multiple conference calls at the same time. During each call the MCU performs additional functions such as bandwidth negotiation, audio duplex selection and 'chair' selection if necessary (where the CODEC determines which party is speaking and gives control of the audio channel that that party).

OIT does not currently operate a public MCU. Information about the NJEDge.net MCU is available at the NJEDge.net website. http://www.njedge.net/

CODEC Standards

All CODECs must be reasonably current with respect to manufacturer code releases. Failure to do this leaves the device vulnerable to performance problems, interoperability problems, application bugs, and security exploits. The table below identifies the currently recommended software versions for popular CODEC manufacturers.

While it is true that many aspects of a video over IP call will autonegotiate during initiation, it is advisable to set them specifically where they are already known and do not vary. Autonegotiation failure will result in consistently poor video quality between devices.

The audio and video compression CODECs are recommended by the NJEdge and Verizon CODEC certification portal. These ensure that a properly configured endpoint can communicate with a peer across the NJEDge.net network. The cited transmission rates represent the best compromise between performance and quality. All CODECs should support both 384K/second and 768K/second data rates.

In order to secure the CODECs, it is imperative that unique passwords be put in place. The RUSecure guidelines for successful password generation can be found here: http://rusecure.rutgers.edu/add_sec_meas/s_passwords.php

In addition to video, many CODECs include advanced features such as simultaneous web-streaming, document sharing and chat. To prevent unauthorized access of these resources, extraneous services should be disabled as necessary. Registration of each CODEC with a gatekeeper can also enhance security, as each device may then be configured to only accept calls from other gatekeeper-registered CODECs.

Conclusion

The quality of video conferencing at the university and beyond is sensitive to all elements participating in the call. The university data network, RUNet, maintains high bandwidth, robust infrastructure capable of carrying these video calls. This reference model provides relevant standards and techniques to ensure that the Local Area Network (LAN) and the video endpoint perform at a suitable level. All elements from the CODEC to the LAN to the university backbone must be compliant before video conferencing can be accomplished in a reliable manner.