Anyone sending media over the public internet will understand the trials and tribulations involved with getting media from A to B without packet loss, increased latency and jitter. Media is usually sent over the internet using UDP rather than TCP which means you can lose bits and bytes while transiting from A to B which ultimately leads to poor video and audio performance.
Broadcaster.VC uses WebRTC in order to get contributors' media streams up to our local cloud SFU and then back into the video production network using the local connector which transforms those WebRTC streams to NDI to ingest into your video mixing software. Typically you want your media to travel peer to peer with as few "hops" in the middle but this is where an optimised TURN network can actually improve things.
As I mentioned earlier, normally, you'd want your traffic to transit peer to peer due to multiple benefits - less latency and less bandwidth cost but some of the time, that peer to peer connection can't be made and we rely on TURN servers to relay the traffic for us - this can be because of a myriad of reasons; a firewall blocking direct connections or IPV4 to IPV6 routing are just two of them.
Historically, the reasons for needing to "relay your media" meant you'd rarely need a TURN server and so using a TURN network from a provider made sense - someone else looking after a service you rarely used makes perfect sense from an operational and cost perspective. There are a number of TURN networks out there with a couple of recent additions; namely Xirsys, Twilio, Subspace and Cloudflare who have launched a beta within the past couple of weeks. Broadcaster VC currently supports Twilio and Subspace.
Announcing Subspace as our default TURN network
Subspace have recently launched their GlobalTURN product which promises to reduce latency and packet loss due to the nature of how their network works - in short Subspace try to get that media off the public internet network as quickly as possible and routed through their anycast network so that it egresses as close to your B peer as possible, meaning it's not transiting the public internet for very long making packet loss etc less likely.
When setting up a room in Broadcaster.VC you can now choose between the default (Broadcaster.VC's choice), Twilio and Subspace. This gives you the flexibility to use the network that works best for you. We hope to add Cloudflare once it's out of Beta giving you even more choice.
Forcing Relaying media
By default WebRTC is setup to only use TURN as the last resort - because traditionally it was the last thing you wanted. Not only are we announcing Subspace as our default TURN network, we're also announcing the ability to force TURN usage; in effect forcing relaying the media over the TURN network in question in order to always gain the benefit of lower latency and less packet loss while in transit over that optimised TURN network.
You can choose this option when setting up a room and this will mean all traffic for that room will now transit that TURN network. There is an additional bandwidth cost for this which will come out of your allowance and excess usage charged at your plan's normal rate.
Soon we'll add the ability to choose whether to failover to the other TURN networks if your chosen one is currently unavailable for whatever reason.
That's all for now folks, thanks for reading.