Self-hosted TURN and Our Experience Using Subspace

Subspace WebRTC-CDN not only delivers STUN and TURN based interconnectivity establishments, but also improves call quality performance for all WebRTC media traffic. This can help real-time communication systems achieve low latency streaming. Such low latency WebRTC streaming is useful for high interactive use cases ranging from online gaming with participant video conferencing to high-quality music streaming/podcasts. 

Figure depicting WebRTC media traffic via Subspace WebRTC-CDN service relay in presence of a restrictive firewall.

Since WebRTC endpoints have dynamically adjustable media capabilities, picture quality takes the worst hit under unpredictable network conditions which are common for low-speed network paths and regions of slow telecommunication data access. By using a custom network to avoid a large part of open internet for transmission, the streams have lower packet loss which leads to a better quality of reception at the remote end. This is depicted in the diagram above where Subspace uses its geographically-distributed Point of Presence (PoP) and dynamic routing algorithm to route the media via the best path using its maintained infrastructure. Useful applications for predictable and high-quality video include video conferencing, e-learning, and telehealth.

Subspace Setup

After setting up an account at https://console.subspace.com/webrtc-cdn, we must set up a Subspace TURN Service and gather ICE server entries for RTCConfiguration using an API.

  1. Create an API key using API ACCESS web console 
  1. Use the client ID and secret to request a token from Auth0
curl -X POST -H 'content-type: application/json' -d '{"client_id": "example_client_id", "client_secret": "example_client_secret", "audience": "https://api.subspace.com/", "grant_type": "client_credentials"}' 

https://subspace.auth0.com/oauth/token

  1. Using the API token, query the WebRTC-CDN credential endpoint.
curl -X POST -H 'authorization: Bearer $TOKEN' 

https://api.subspace.com/v1/globalturn

  1. Using your TURN client, connect to any of the returned URLs.

Try out https://subspace.com/api#/WebRtcCdnService/WebRtcCdnService_GetWebRtcCdn

Screenshot of WebRTC media session via Subspace WebRTC in restrictive firewalls setup.

Subspace WebRTC-CDN Performance 

A TURN service that leverages its PoPs for media path optimization performs better. A self-hosted service is favorable for local firewall bypassing connections, but this could become a possible bottleneck in hairpin scenarios or an unbalanced focal point in the TURN relay session. Taking a closer look at how Subspace’s TURN service WebRTC-CDN performs shows a more predictable QoS stat across many call samples. Unlike self-hosted TURN, which varies across call scenarios.

Screenshot of WebRTC media session via Subspace WebRTC-CDN. 
ICE candidates: Local udp prflx, Remote udp relay 

Diving deep into the stats collected from the WebRTC Internals dump and using webrtc-dump-importer @fippo showed a packet loss ~12. This is in sharp contrast to self-hosted TURN, which has a packet loss ~50.

Packet loss and total round trip time on a two peer WebRTC call via Subspace WebRTC-CDN.

Performance for relay candidates Subspace WebRTC-CDN against self-hosted CoTURN 

CoTURN is an open-source STUN and TURN-supported ICE Server which is frequently used for RTC (Real Time Communication) systems. 

Screenshot for bitrate performance of CoTURN established media session. 
ICE candidates: Local udp prflx, Remote udp relay 
Screenshot for bitrate performance of Subspace established media session.
ICE candidates: Local udp prflx, Remote udp relay  
Heavy packet loss using COTURN relay candidates ( may or may not be at the focal point of the session)

Isolating specific metrics like packet loss and RTT for inbound streams and relay ICE candidate pairs and porting the parsed data over to Jupiter notebook for Exploratory Data analysis, the WebRTC-CDN service provided by Subspace shows a significant improvement noticed in packet loss. This leads to better stream reception for the remote endpoint. Some of the features that did not show much difference between the two TURN servers were FIR, PLI, and NACK.

Error handling via RTT for Inbound Video stream using TURN relay

While jitter and delay are related, jitter is a better metric for gauging packet loss and congestion. Whereas delay measures the time taken to send a packet from one peer to another, jitter measures the difference between the delay of packets. Analyzing the WebRTC dumps collected from the two kinds of turn relay setups show comparable jitter performance.

jitterBuffer via TURN relay

Long distance peer-to-peer communication

QoS For long distance Communication using WebRTC CDN relay ICE candidate pair.

The QoS attributes of a Subspace WebRTC-CDN established media session between distant geographic regions (US West and Australia using ICE candidates vs COTURN self hosted setup in US West) is shown in figures below. Both cases have Local udp prflx and Remote udp relay candidates.

Packets sent per second via TURN relay
Packets received per second via TURN relay

There is a relative flattening of outgoing bitrate and packet received rate. This peak shaving leads to predictable performance and better response from network resources (internet routers/gateways) in the path of the media stream.

Round Trip Time (RTT) for Inbound RTP Video Stream is comparable. Due a large distance between the peer endpoints, the RTT is higher than usual.

RTT via TURN relay

Observations from the long-distance communication indicate that the roundtrip time was considerably higher across all cases, which is expected due to the large distance and multiple network resources in the path. However, Subspace performed significantly better than CoTURN in managing packet loss. On the other hand, the CoTURN self-hosted setup shows better performance in sessions within a small region.

Force relay on both ends of WebRTC session 

Even though “all” is the default ICE transport policy in WebRTC configuration, we can force the WebRTC client to only use only “Relay” candidates in its path with configuration.

var pcConfig = {
 iceTransportPolicy: 'relay', // make relay mandatory
 "iceServers": [{ .. }]
}

The performance of using only relay ICE candidates shows a smoother (predictably linear and correlated) output.

Screenshot of WebRTC media session via Subspace WebRTC-CDN.
ICE candidates: Local udp relay, Remote udp relay 
Screenshot for bitrate performance of Subspace established media session. 
ICE candidates: Local udp relay, Remote udp relay 

Observations on comparative performance of prflx + relay ICE candidates vs relay only Ice Candidates show less fluctuations in bytes received in the latter. A better (flatter, hence more predictable) outgoing bitrate leads to stable connection. The user experience of stable picture quality was noticeable across various network scenarios when using forced TURN relay, as compared to using a STUN based peer reflexive address.

In conclusion, TURN is a must for service reliability across firewalls and cross-network. A distributed Point of Presence setup across geographies can significantly lower the risk of packet loss as opposed to an uncertain dynamic route via the public internet. Media path optimization and low latency algorithms are the future for all RTC applications.

Given the increasing trends of remote work, learning, and entertainment, having a predictable network relay performance can take the stress off the communication service provider. This allows them to focus on value add-ons, such as intelligent call respondents or automatic minutes-of-meeting, rather than extracting root causes for low QoS scores in network edge cases.

About the Author: Altanai Bisht

Here at WebRTC.ventures, we pride ourselves on offering our clients the opportunity to work with extremely bright developers, like Altanai. Don’t trust your custom video solution to just anyone. Trust the experts!

©2022 KLEO Template a premium and multipurpose theme from Seventh Queen

Log in with your credentials

Forgot your details?