In the olden days of IP-based Outside Broadcasts, one needed to do port forwarding to get bidirectional audio. Then NAT traversing codecs started appearing (such as the Telos Z/IP One). These removed a lot of the hard work of getting an OB link setup. However, NAT traversal isn’t enough to get through some heftier firewalls.
In order to get a recent outside broadcast off the ground, I setup a VPN tunnel that connected via a HTTP Proxy. I was unsure what sort of performance I would get, but testing revealed a solid 1.8Mbps connection both ways and not much latency at all.
Here’s what the setup involved:
- OpenVPN Access Server hosted on Digital Ocean droplet (VPS)
- OpenVPN Client on Ubiquiti EdgeMax Lite Router
- Tieline Z/IP One and Tieline G3 Codecs
- A lot of trial and error
The conditions on the remote network were tough:
- No open ports
- All web traffic connected via strict HTTP Proxy
- Difficult/impossible to get people to open ports in time
That’s why I opted to create a VPN.
What is a VPN?
A VPN is a Virtual Private Network. It is essentially a secure ‘container’ which you can route your IP packets through. VPNs are typically used for:
- Remote access to networks
- Secure internet access via untrusted networks (e.g. public WiFi)
- Circumventing geo-blocking
- Anonymous browsing
- Getting traffic through a strict firewall
Here, we are getting the VPN to negotiate a connection with the existing web proxy and create a secure ‘tunnel’ into the outside world. The codec will see this as just a regular route, and act as it usually does. The tunnel masks what is really happening.
The VPN Technology
I chose to use OpenVPN as the VPN tunnel technology for this remote outside broadcast. There’s a few reasons:
- It runs over TCP port 443
I knew I could get out of the proxy using port 443, because I’d tested it with my SSH server
- It fully supports UDP packets
Streaming media is built around UDP packets. The two codecs I had access to used UDP to transmit audio.
- It’s cheap
- It’s fairly easy to setup
- Supports tunnelling via a proxy
I’m not going to go into great detail here on how to set this up, as I’ve already written about it before. Here’s the two major, broad-strokes steps:
Here’s a flow chart of how the components connect:
As you can see, the EdgeMax router as the VPN ‘client’ create a tunnel and uses that tunnel to send all data to a server sitting on the internet. The location of your VPN ‘server’s isn’t that important. It could be in the cloud, or on your station’s network. I opted for the cloud because it would be easier for me to setup.
Performance and Findings
This VPN performed very well on it’s first outing.
When I was prototyping this at the office, I experienced some audio ‘glitching’ (encoding artefacts from dropped packets). I found with the Z/IP One it was best to fix the buffer and bitrate so it didn’t try to adapt. Because the tunnel is actually masking a lot of network hops and also retransmitting lost packets itself, I think the Z/IP One got a bit confused. By fixing the settings and removing the adaptability it made the unit more ‘dumb’ and forced the work back onto the VPN algorithm.
Latency was about a second each way, although we probably could’ve lowered that with a bit of fine tuning.
Running the Tieline G3 over the same VPN produced similar results. We were able to get a high bitrate and a lowish buffer time using the “MusicPlus” algorithm.
Remember: It’s best not to run multiple things over the one VPN. Because of the processing involved in the VPN software, unnecessary packets can cause issues with the audio. If you need multiple connections, consider multiple VPN tunnels to isolate everything.
Why the two codecs? We were hedging our bets. During the broadcast we had one codec on 4G and another on the VPN. In testing though, we had both running over the VPN at different stages.