We seemed to have reached a milestone in our IP journey as more broadcasters are able to distribute live video and audio over private networks and even the internet. So, what’s next?
I often liken our current stage of broadcast IP to the internet of the 1990s, it was new, and we had many challenges to solve. Installing an ISDN driver card into a Linux server was tantamount to running an intellectual marathon as there was no plug-n-play, and very little in terms of experience. But the results were worth it, not only did ISDN provide near instantaneous dial-up, but it also delivered 128Kbits/sec. Compared to the 38,400Kbits/sec for a PSTN dial-up (if you were lucky), then surfing the internet was a joy to behold.
Now, we can walk into any room and be inundated with WiFi connectivity, and on the few occasions this isn’t available, 4G (and soon to be 5G-NR) is waiting as a backup. Not having an internet connection is now the exception, not the norm. And the key to our Quality of Experience is the ease with which we connect to the internet.
In many respects, this is where we are with our broadcasting IP journey. When it works well it works really well, but making it work is a challenge. The great news is that there are vendors and industry organizations who are working hard to improve the plug-n-play experience.
One of the challenges we have revolves around maintaining IP addresses. With the thousands of video, audio and metadata sources, it’s very easy to lose count of the IP addresses and how they are allocated to the various devices. Keeping a massive datasheet may work for static systems, but the whole point of IP infrastructures is that they must provide scalable and flexible systems. Therefore, a dynamic approach is not only beneficial, but a necessity.
Again, we can learn much from IT. To solve this challenge, they use DHCP (Dynamic Host Control Protocol) to allocate IP addresses automatically. And then we have DNS (Domain Name System) to allocate names to devices to form another level of abstraction from a devices IP address. For example, if camera one in studio one is assigned the label “Studio1-C1-HD-output", then the DNS system will allow the IP address to be changed independently of the label. This way, the system users do not need to keep a list of all the IP addresses. Yes, this requires planning and policy decisions to make the DNS and DHCP servers operate effectively, but it is a proven solution. And if you don’t want to build your own DHCP/DNS solution, then there are vendors who are designing and building broadcast specific solutions to deliver similar functionality.
Another consideration is that of security. If a journalist wants to download media from their ENG camera, then the system needs a method of identifying the device, allocating it an IP address, and downloading the material, preferably into a DMZ (Demilitarized Zone) or something similar. This way the device can be validated, and the material checked for viruses before it enters the network. In other words, the DMZ acts as an exposed point to untrusted networks and devices.
Although we should look to IT to find the solutions to many of the plug-n-play type challenges we are currently facing, broadcasting is unique and should be treated slightly differently. Our timing constraints, massive thirst for data bandwidth, and working practices demand flexibility and scalability and vendors who understand this are designing and building IP solutions that meet the needs of broadcasters.