Network administrators want to be fully in control of their networks. And rightfully so, as they are responsible for keeping a big complex beast running like a Swiss watch. So their preference is to decide for themselves which packet streams should get high priority, and which should be constantly relegated to the lower classes. But this doesn't work very well for video conferencing.The problem is that the audio and video streams associated with a video conference use dynamically assigned UDP ports, determined at setup and determined by the equipment in use. Each vendor has chosen a default range of UDP ports that their equipment uses. Different equipment from the same vendor often uses different port ranges. So it is difficult to pin down a classification methodology for the router that will uniquely identify a packet stream as being the video or audio from a video conference.
Some of my customers solve this issue by identifying the IP addresses of the video conferencing equipment and marking all traffic from those endpoints as high priority. While this approach will reliably mark the voice and video as high priority, it comes with a number of downsides as well.
Not all packets emanating from a video endpoint are video. Two other types of traffic exist, signaling and management. Signaling traffic consists of small packets and low bandwidth, so it causes very little interference with voice and video. But management traffic can provide the typical large bursts of utilization of any data application that momentarily jam queues, cause jitter and packet loss and affect the quality of a video conference.
Management and signaling traffic are carried by TCP rather than UDP, so the first step to solving this issue is to only mark UDP packets from video conferencing endpoints with a high priority marking. This gets us most of the way there. But a better long-term approach is to establish trust with the endpoint, and then honor the endpoint markings.
The video conferencing endpoint always has better information than the network about which streams should be given high priority and which should not, because it is running the application. The endpoint can then mark those packets and send them into the network pre-identified. But if the network does not trust the endpoint because it cannot be easily verified that this truly is a video conferencing endpoint and not a hacker on a PC, then the network administrator is more likely to choose the option that keeps him in control as described above.
Today I most often recommend an approach that uses IP addresses or ranges to uniquely identify video equipment, and then to trust the markings from those endpoints. This approach solves the trust issue for the network administrator, while still leaving the final decision about which packets are high priority and which are not to the endpoint.
In telephony we have solved this issue (not always in a standardized way) by creating a verification protocol between the network and the telephone handset to verify that it really is a telephone and should be trusted. This technology will eventually migrate into video conferencing and eliminate the need for identifying endpoint IP addresses. Ask your vendor for this feature. But in the meantime, build a classification methodology that uniquely identifies the audio and video streams without compromising the network.
