Widgets Magazine

AV Control And Web Technologies

There is no denying that the network has had an enormous impact on AV control systems. But we have mostly been limited to low-level TCP connections. I’ve even heard this referred to as “Serial Over IP.” To take advantage of the cloud, responsive web pages, mobile apps and other Internet services, we’ll need to get familiar with some of the common communication protocols found on the web. But first, let’s peel back a few network layers to get a better understanding of how systems work.
What The OSI And TCP/IP Models Mean For AV Control
The OSI model describes network communication standards in seven layers, and the TCP/IP Model has four layers. In both models, each layer is responsible for certain functions and relies on the layer below it. When you hear network switch manufacturers talk about a layer 2 or layer three switch, this is what they mean. The layer three switch can “do more” because it is higher on the model and includes all the layers below it.
It is important to note that these models are an attempt to understand and categorize a complex chain of communication protocols. Some protocols do not fit neatly into any of these layers and can even appear in several layers at once. The OSI and TCP/IP models are useful tools to help us understand how networks work, but they are not always capable of explaining everything perfectly.
For AV control, we are interested in the layers that will help us communicate between different devices. The first layer that does this is the transport layer (layer 4 in the OSI model and layer 3 in the TCP/IP model). There are many transport protocols available, but the ones most often found on AV devices are TCP and occasionally UDP.
The biggest difference between these two protocols is that UDP does not check or acknowledge if a message was received. If a UDP message does not reach its destination, it is simply dropped. UDP is often used in multicast and broadcast situations, where retransmitting messages to multiple recipients would be too cumbersome.
TCP on the other hand guarantees that messages will reach their destination. It performs error checking and requests retransmission of lost packets. Other protocols are built on top of TCP, but many AV devices are capable of communicating with this protocol alone.
TCP and UDP exist on the lowest layer on which you can send messages. The messages are sent in plain text without extra formatting. This is sometimes referred to as a raw socket. It would be helpful if the AV community could agree on a term that refers to devices capable of communicating with TCP or UDP. Something like Transport Layer Control Device? Just an idea…
Above the Transport Layer, the OSI model defines three more layers while the TCP/IP model has only one. In both models, the top layer is called the Application Layer, and this is where most “higher level” protocols are described. The OSI model attempts to describe encryption protocols like SSL and TLS somewhere between layers 4 and 7. This is kind of a gray area that the TCP/IP model makes easier to understand by describing it all in one layer. Since our primary goal is to send messages between devices (and not get lost in the complexities of encryption), I will take the TCP/IP model approach and only talk about the Application Layer.

Some common Application Layer protocols that are useful to control and automation systems include HTTP, HTTPS, and Websockets. All of these protocols are built on top of a TCP connection and transfer information in different ways. Can we agree to call an AV device that supports these control protocols an Application Layer Control Device? Just putting it out there…
HTTP uses a hyperlink or URL to request a resource from a server. An HTTP server is just an application on another computer that listens for HTTP requests. Once a request is received, the server sends a response. The server may also perform some functions before sending the response.
After the exchange takes place, the conversation is over. The underlying TCP connection is disconnected and deleted. The server has no way to send information to the client again unless the client first makes another request.
Many services on the internet use HTTP to communicate. An API or Application Programming Interface describes how to use the different functions of a service. As an example, NASA has an API for finding out who is in space right now. It looks like this:


If you type that URL into a web browser, a server will pull some data from a database and return it to your web browser. The response looks something like this:
{“number”: 5, “people”: [{“craft”: “ISS”, “name”: “Oleg Novitskiy”}, {“craft”: “ISS”, “name”: “Thomas Pesquet”}, {“craft”: “ISS”, “name”: “Peggy Whitson”}, {“craft”: “ISS”, “name”: “Fyodor Yurchikhin”}, {“craft”: “ISS”, “name”: “Jack Fischer”}], “message”: “success”}
So how does this apply to control? In order to use most Internet services, HTTP is required. Things like remote management systems, online calendars and databases are some typical examples of online services that could be integrated with AV systems.
Some devices even use HTTP to be controlled locally. A control processor or user interface needs to support HTTP to control such devices.
HTTPS is a secure version of HTTP. With HTTPS, information is encrypted before being sent and decrypted when received. Encryption makes messages difficult to read if they are intercepted during transmission.
HTTPS also authenticates the identity of the server. Authentication helps confirm that you are communicating with the intended server and not an imposter.
For security reasons, it is not possible to open a raw TCP socket in a web browser. But there are times when a two-way, full-duplex connection over the internet is desirable. Websockets solve this problem.
A web socket is a Transport Layer TCP connection. But a handshake needs to happen first before the connection is made. This handshake happens with HTTPS. By using HTTPS for the handshake, Websockets gain all the security of HTTPS, allow two-way communication through firewalls over standard internet ports and can freely send information in both directions.
While web sockets technically operate on the Transport Layer, the initial handshake requires HTTPS – an Application Layer protocol. For this reason, it makes sense to think of web sockets as an Application layer protocol. No HTTPS means no web sockets.
Just like networks changed the way AV systems and devices are designed, web technologies are also finding their way into our world. Knowing the technology requirements for different protocols is the first step in selecting the right equipment for a system. I hope this article helps the AV community agree on some new terminology so we can communicate more clearly and take advantage of all the fantastic technologies available today.
Patrick Murray, CTS
Patrick Murray has been working with audiovisual systems in one form or another since 1995.
After moving to Germany in 2005, he founded Controlhaus and began developing automation and control software for mega-yachts, luxury homes, command and control centers and a few conference rooms along the way.
Patrick is on a mission to encourage the AV Community to create amazing applications with modern, non-proprietary software.
He loves to learn, hang out with his family and be creative.

About Author


No Comments

  1. Avatar

    Overall nice article. Just an FYI, Websockets do NOT require HTTPS. That is incorrect. They work with standard unsecured http.

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.