In this continuation on my Videoconference basics series (see part 1 here), I want to discuss some of the underlying data transfer “styles” when calling over IP networks. The beauty of using a TCP/IP network is that regardless of what the data “is” the network set up for transferring the information works the same fundamental way.
All IP based communications between devices are sent either as TCP (Transmission control protocol) or UDP (user datagram protocol) packets. Without going too head over heels with detail, a packet can be thought of as basically a piece of encoded information (the “payload”) wrapped in a header. The header contains addressing and other behind the scenes mechanisms to ensure the packets get where they need to go.
TCP Packets
A TCP Packet contains a mechanism that will ensure delivery. If it is not acknowledged, it can be resent until it either goes through or the sender can time out. This is great for a lot of communications that require acknowledgement of receipt of data. This does come with a price though, and that is speed of delivery. All the overhead required to ensure delivery makes it take longer, and all the packets might not come out in the correct order at the other end. For most internet applications, this is actually not a problem. Think of a web page where all the data is presented on a page. Behind the scenes, your computer requests data from a server and gets sent back a bunch of information. Some packets might get dropped, so are re-sent and your computer assembles all the data in order before displaying it to you.
So where am I going with this? Getting back to Videoconferencing, we do need to get all the information, but it is actually more important that we get it in real time rather than making sure we don’t miss anything. Missing a couple of packets here and there doesn’t affect the flow of the conversation. There are also error correction algorithms in place during a video call that conceal minor levels of dropped packets. You can afford to drop some packets but what is more important is that you keep getting new information.
Enter UDP Packets
The way we get real time packet delivery is through the use of the other IP packet type, UDP. With this type of packet, the information is constantly sent out without waiting for acknowledgement. If the receiving side misses something, the sender does not care. Think of it as shouting through a megaphone at the world. You don’t care if anyone is really listening, you just keep shouting.
UPD packets are used for other real time communications in control applications as well. Although you might hear or see a glitch now and then you are not loosing the flow of the conversation, or the constantly updating information stream.
How H.323 uses TCP and UDP packets
So now that you know a little bit about the types of packets, you have a better understanding of what they are used for and why. A Videoconference call over H.323 actually makes use of both types of packets. TCP is used for call setup and control, while UDP is used for the actual video and voice transmission. While the UPD packets are typically dynamically allocated during each call, there are some common ports that are used that you should be aware of:
An IP network is comprised of multiple network segments that are routed. At each routing point, you may have systems in place that could affect the flow of data packets. There is a mechanism available called QoS which will allow you to prioritize your data so that it gets delivered more reliably. You can set this on the codec, but it needs to correspond to how things are set on the network gear. This involves cooperation with the IT people to get everything working smoothly.
Fireall Traversal
Depending on the environment, getting through the firewall may be as simple as setting up a NAT (Network Address Translator) to forward incoming videoconference traffic to the endpoint behind the firewall. In this basic application, you could only ever have one endpoint behind a firewall. There is also a setting in the videoconference codec to enable NAT mode. Basically what this does is insert the publicly accessible IP address into the outgoing packet stream so that the far site knows where to direct its UDP stream.
In more advanced firewall traversal applications, you could implement a firewall traversal server which can be thought of as a network appliance in parallel with the main firewall. The details on how to implement this method can vary depending on a lot of factors, so it is best to refer to specific manufacturer information on this.
The biggest note involving firewalls is that they are a security risk for the IT departments. They would defiantly need to be involved in any work involving changes to the firewall, and depending on the organization may require a completely separate videoconference network.
Conclusion
With that, I think I have covered off many of the major points about the inner workings of videoconference systems. A lot of the details can quickly get into fairly advanced networking and you definately need some skill in that field to be effective at setting up and troubleshooting videoconference endpoints. Be sure to check out my article Introduction to Networking for Pro AV
I’d like to hear your thoughts on firewall traversal, specifically some of the challenges you’ve faced and how you’ve dealt with them. Let me know by leaving a comment below.
