Thirty years ago, the majority of intercom systems in the U.S. were based on the two-wire party line concept, not unlike the hand crank telephone your (great) grandmother had on her wall with “Ernestine the Operator” organizing a “one ringy dingy” style connection, often so she could listen in with everyone else. (Those younger than 45 can start their favorite search engine, now.)
Such systems meant — in the simplest terms — that there were one or two channels of communication that were used by everyone. Stations using such systems survived with headsets to communicate with their control room rather than open microphones and speakers, which doesn’t work particularly well on a two-wire system given the number of operators in the same room. All you get is acoustic feedback. A comms system based on a series of headsets plugged into a single twisted pair of wires may sound very simple, and they were. All you needed to connect the headsets was old-fashioned analog microphone cable and an XLR three-pin connector to link various boxes, headset stations and beltpacks.
However, the byproduct of such an approach was that it was not only highly limited, but subtly divisive. You were either a Channel A person (production personnel perhaps) or a Channel B person (the engineers). If you were lucky (or unlucky), you could hear a cacophony of both channels mixed together. It also had the effect of stopping people from constantly talking because they knew what they said could be heard by everyone on their line, which in some cases was not necessarily a bad thing.
Beyond two-wire systems
Things soon got a lot more complicated, though. Two wires simply weren’t enough for more contemporary productions. Expansions to four-channel and eight-channel party lines soon led to spaghetti bowls of cables, devices, interface boxes, splitters, source assignment panels and IFB controllers — all of which had to be assembled, maintained and configured by an experienced audio engineer who knew what he or she was doing. And that is not to mention the confusion over who was, or should be, talking to whom.
However, major U.S. and European networks soon moved to four-wire matrices, where everything was linked to a single central matrix, and all comms functions were performed within that matrix. Legacy party-line beltpacks for the studio floor crew went through two- or four-wire adapters to convert them for use with a four-wire matrix. They would still communicate on one or two channels, but those channels were all connected to a central matrix, and that required a lot of cable.
Digital revolution
It all changed when matrices went digital in the ’90s. Comms systems suddenly morphed from requiring hundreds of bits of copper wire to transporting millions of bits of data over Cat 5 cable or a length of coax. Connections between key panel stations via Cat 5 or coax to the central matrix considerably reduced the need for hundreds of bits of wire, and the millions of bits of data meant that the matrix-based systems could become much more sophisticated with digital displays on control panels, PC configurability, and a limited degree of diagnostics and monitoring.
IP
It was only at the turn of the 21st century that the concept of IP-based systems started to emerge, and with all things new, there were naysayers who declared that it couldn’t be done. Throughout the 2000s, we encountered a lot of resistance from traditional broadcast engineers who said, “Well, that may be what the IT guys think, but they don’t understand broadcast, and we don’t understand IT.” Communication, they reasoned, was simply too important to trust to perceived IT infrastructure issues of bandwidth and latency limitations. Some still argue the point today, but those voices are fading rapidly, and here’s why.
In fairness, there was a lot of new information for both sides to get their heads around. It was difficult. Broadcast engineers weren’t familiar with IP gateways, subnet masks and the like. IT folks couldn’t get to grips with broadcast workflows. It’s taken a while, but video and audio file transfer mechanisms over IT infrastructures are becoming the norm. Slowly but surely, IT and broadcast professionals have coalesced into a far more mature, constructive and mutually beneficial partnership.
If you compare an IP-based comms system with four-wire matrix technology, one major differentiator leaps out: An IP-based intercom doesn’t require bespoke infrastructure. It can use the existing IT infrastructure to establish reliable connectivity and functionality between matrices over a LAN.
As more and more people began to understand and become comfortable with IT and what it could do, the benefits of sending audio over IP — such as connecting intercom panels, matrices and VoIP phone systems — became clear. Suddenly, a satellite truck in Poughkeepsie could be connected via satellite and the local talent receive an IFB feed from the studio back in Des Moines — all over IP rather than old-fashioned phone systems, microwave links, etc. Voice communication at the truck could be easily integrated with the main station’s intercom, all over IP, and that’s the crux of the benefits of an IP-based system — the ability to seamlessly interconnect multiple, and sometimes disparate, devices. However, it required a whole new world of common understanding and a lot of research and negotiation to get there, some of which is ongoing.
Session initiation protocol
Today, the trend is for VoIP intercom systems to incorporate session initiation protocol (SIP) connectivity for use over redundant fiber networks. Although SIP looks like a protocol, walks like a protocol and talks like a protocol, it is not, in and of itself, a protocol.
SIP is a somewhat confusing acronym because it isn’t a protocol in the sense of defining a codec, which of course details the parameters of an IP stream such as bandwidth, audio quality, packet size, latency, etc. What SIP actually represents is a characterization of how two devices should establish communication. Within that characterization are a number of codecs, which can be loosely described as communication protocols.
To use a simple analogy, SIP provides the introductions between multiple devices without knowing initially what language each device speaks. SIP will scan its database of languages (codecs) and negotiate the preferred common language (codec) that will enable the devices to converse with fluidity and complete understanding. SIP is, in effect, the matchmaker that enables interoperability.
Intercom vendors have spent the better part of two years involved in an on-going dialog with an EBU technical team formed to establish a common standard (EBU Tech 3347) for intercom compatibility between manufacturers. At one point, the EBU team organized a “Plug Test” between intercom vendors and manufacturers to establish whether their systems could indeed “talk” to one another. The aim for European broadcasters was to distance themselves from dependence on ISDN lines for interconnection as ISDN was in the process of being phased out for comms and program audio purposes. There are perhaps parallels in the North American market that should be considered. The result of the one-to-one testing was, overall, encouraging, but it was also clear that a great deal of work remains to be done to ensure that audio over IP can be shared between intercom devices, no matter whose name is on the box. That works continues today.
Recent improvements
The development of comms interoperability standards is still in its early stages, but we have already used SIP-compliant technology to establish intelligent communication between systems. In a recent demonstration, an operator of one intercom simply pressed a panel key that was configured to talk to a specific operator using a completely different system at another location. Using SIP, the system called the other and said, in effect, “You have a call from another system,” and audio connectivity between the two was established immediately.
This is a completely new and previously unheard of approach in multivendor comms systems. It’s never been feasible before, but what’s more important from a user’s perspective is that it opens up huge possibilities for improvement by removing dependency on a single supplier. Suddenly it becomes possible to choose technology from multiple vendors rather than be tied to a single system that may not be performing to modern standards yet is too expensive to replace in its entirety.
Figure 1. With IP-based systems and SIP-compliant interoperability, it is now possible to establish multisite communication to sat trucks, news bureaus and affiliates over common and multivendor comms systems — all via IP.
With IP-based systems and SIP-compliant interoperability, it is now possible to establish multisite communication to sat trucks, news bureaus and affiliates over common and multivendor comms systems — all via IP. (See Figure 1.) It doesn’t matter if multisite means the next room or the other side of the world. The design of modern matrix technology includes the whole IT infrastructure it is destined for, plus built-in IP capability and SIP compliance from the start. It’s no longer something you have to add boxes or fiddly software to achieve.
Distributed matrix
Let’s now examine what’s called the distributed matrix concept. It’s subtly different from a centralized IP-based matrix.
Consider a new intercom system — perhaps your own — to be located in a 10-story building. The facility will include multiple studios, master control, edit suites, playout and lots of other areas, all connected by a conventional four-wire system tied to one large matrix — 64 x 64 , 128 x 128 or 256 x 256 — in a central apparatus room. Such a design requires everything to be cabled back to it.
If the cameras are located in studio A, you have to run cables back to the central apparatus room. The same with interfaces, control panels, everything. Engineers have to find their way through the ducting of the whole building to run cables to a central point somewhere else, perhaps quite some distance away. Such a solution is often disruptive, costly and time consuming.
With a distributed matrix system, you can avoid all of that by physically breaking the big central matrix into three or four smaller matrices, or nodes located throughout the building. The nodes are connected via multichannel digital audio with built-in redundancy on an IP platform. Voilà! You have a modern, IP-based distributed comms matrix architecture. The production team, engineering staff, directors, station managers, finance director and IT guy will immediately appreciate the numerous advantages, one being that they only have to talk to each other if they want to.
—Malcolm Reed is projects manager, Trilogy Communications.
