In our newsletters we’ve focused on the importance of the layer four protocols, TCP and UDP. This is important to understand so that now we can discuss how each of the major categories of IP video behaves on an IP network. In the next few newsletters we’ll look at each of the following video types: video conferencing, IPTV, adaptive bit rate video and surveillance video. IPTV will include other forms of video that depend on using the mpeg transport method such as digital signage. What we want to learn is how each type of video behaves on an IP network and what to look for when you are troubleshooting or monitoring the traffic of that type of video.
We’ll start with video conferencing (VC). This type of video is different from the others because there are two or more endpoints simultaneously sending audio and video. Each endpoint ingests the audio and video signals and sends them to a device called a bridge. The bridge, now often called a VC server, recreates the video in a form that is appropriate to the needs and requested format of the other endpoints. Thus, an audio/video stream might come into the bridge from Endpoint A but the signal going out to the partners at Endpoints B, C, and D will be four images and potentially four audio signals combined on a single display device and a single output speaker.
In its earliest implementation, the underlying network was the public telephone network. Large display devices were connected to encoders at each location. The codec, which often was H.262, which was based on a standard written by the telecommunications industry. The underlying circuits were T-1 links or fractional T-1 links. This was all very expensive to operate.
Today, nearly all video conference endpoints are connected to IP networks. They use UDP as the transport protocol. Consequently, they are very sensitive to network loss and high network jitter. The codecs employed are frequently H.264. As a result, it is possible to send and receive HD video. Transcoding video from standard to high definition is a bridge function.
To overcome the issue of network jitter, endpoints use a jitter buffer which can expand and contract based on network conditions. In order to properly detect lost packets, RTP (Real-Time Protocol) is added to the audio video stream. It identifies the audio and video sources and will label the packets with a sequence number. If packets are dropped, the receiving codec usually has an algorithm for estimating what the audio or video should have been. This is often called error concealment. An additional protocol, RTCP (Real-time Control Protocol) can also be used. At fixed intervals, the receiver reports the rate at which packets were lost to the sender. If the network is expected to exhibit loss, codecs can use forward error correction (FEC), This is a system where additional bits are added to the stream to allow the receiver to fix damage payloads.
The combination of UDP and RTP tells us that the network needs to be as free from errors and jitter as possible. This certainly is not a description of the Internet. So, to use VC over the Internet, you’ll likely employ either a system that uses SVC (scalable video coding) or WebRTC. Both of these technologies are possible topics for a future newsletter. To monitor and troubleshoot VC traffic, there are a variety of tools that report network loss and jitter. Some are quite inexpensive like the free tool Wireshark.
In our newsletters we’ve focused on the importance of the layer four protocols, TCP and UDP. This is important to understand so that now we can discuss how each of the major categories of IP video behaves on an IP network. In the next few newsletters we’ll look at each of the following video types: video conferencing, IPTV, adaptive bit rate video and surveillance video. IPTV will include other forms of video that depend on using the mpeg transport method such as digital signage. What we want to learn is how each type of video behaves on an IP network and what to look for when you are troubleshooting or monitoring the traffic of that type of video.
We’ll start with video conferencing (VC). This type of video is different from the others because there are two or more endpoints simultaneously sending audio and video. Each endpoint ingests the audio and video signals and sends them to a device called a bridge. The bridge, now often called a VC server, recreates the video in a form that is appropriate to the needs and requested format of the other endpoints. Thus, an audio/video stream might come into the bridge from Endpoint A but the signal going out to the partners at Endpoints B, C, and D will be four images and potentially four audio signals combined on a single display device and a single output speaker.
In its earliest implementation, the underlying network was the public telephone network. Large display devices were connected to encoders at each location. The codec, which often was H.262, which was based on a standard written by the telecommunications industry. The underlying circuits were T-1 links or fractional T-1 links. This was all very expensive to operate.
Today, nearly all video conference endpoints are connected to IP networks. They use UDP as the transport protocol. Consequently, they are very sensitive to network loss and high network jitter. The codecs employed are frequently H.264. As a result, it is possible to send and receive HD video. Transcoding video from standard to high definition is a bridge function.
To overcome the issue of network jitter, endpoints use a jitter buffer which can expand and contract based on network conditions. In order to properly detect lost packets, RTP (Real-Time Protocol) is added to the audio video stream. It identifies the audio and video sources and will label the packets with a sequence number. If packets are dropped, the receiving codec usually has an algorithm for estimating what the audio or video should have been. This is often called error concealment. An additional protocol, RTCP (Real-time Control Protocol) can also be used. At fixed intervals, the receiver reports the rate at which packets were lost to the sender. If the network is expected to exhibit loss, codecs can use forward error correction (FEC), This is a system where additional bits are added to the stream to allow the receiver to fix damage payloads.
The combination of UDP and RTP tells us that the network needs to be as free from errors and jitter as possible. This certainly is not a description of the Internet. So, to use VC over the Internet, you’ll likely employ either a system that uses SVC (scalable video coding) or WebRTC. Both of these technologies are possible topics for a future newsletter. To monitor and troubleshoot VC traffic, there are a variety of tools that report network loss and jitter. Some are quite inexpensive like the free tool Wireshark.
