How we tested video frame relay

Our tests were designed to determine if these products could employ economical frame relay WAN services and still deliver the quality we'd expect from room-based videoconferencing systems. First, we attempted a video call in the absence of any other traffic. Next, for the ACT Networks and Memotec Communications systems only, we introduced a high volume of data traffic over the Ethernet interfaces to study the FRADs' ability to protect the high-priority video stream from low-priority IP traffic.

We drove most of the tests with a pair of PictureTel Corp. Concorde room videoconferencing systems in H.261 ýfull CIFý resolution (352 x 288 pixels). G.722 was set for audio compression. Our baseline used ISDN performance as the target for quality, so we first connected these through a pair of Ascend Communications MB-T1-BDC3 inverse multiplexers running at 384 Kbps. The PictureTel systems performed at their rated speed: 30 frames per second.

To measure video performance objectively, we replaced the PictureTel camera and microphone inputs with a VCR that played the Network Computing Video Codec Benchmark tape, which contains a series of test clips overlaid with visible frame numbers. We also used a tape obtained from IntelCorp. that measures audio lip-sync delays. Another VCR was connected to the receiving PictureTel system and all output was recorded for frame-by-frame analysis. The ABL Canada VT2C Apollo and Motorola RemoteVU systems have built-in codecs, so we connected the VCR directly to their user input camera/line-in ports.

We conducted our tests at the MCI Developer's Lab in Richardson, Texas, using MCI's POPs (points of presence) in Chicago and Memphis. Access circuits and port speeds ran at 768 Kbps (12 DS-0s). We used a single frame relay PVC, and expected the FRADs to multiplex the video and data streams when applicable. The FRADs reported a nominal one-way delay of 42 ms across the frame relay network.

To test the FRADs that route Ethernet data (Memotec and ACT), we used a Wandel and Goltermann DA-30C analyzer running the RTBench application, set to send up to 1 Mbps of IP traffic. RTBench gradually increases packet size and bandwidth to determine maximum loss, less throughput and latency.

On the FRADs, we set traffic priority for the data stream as low as possible and put video traffic in a higher class. It's acceptable to drop or buffer IP traffic, but unacceptable for this traffic to affect the video call.