The basics of WebRTC
Jugo delivers real-time media streams using the WebRTC protocol suite for peer-to-peer communication of audio and video data from a browser application. The following network connectivity settings are required for clients to successfully establish WebRTC peer-to-peer connectivity with Jugo.
STUN, TURN, and ICE are a set of IETF standard protocols for negotiating traversing NATs when establishing peer-to-peer communication sessions. WebRTC stacks implement support for ICE to improve the reliability of IP communications.
A client uses Session Traversal Utilities for NAT (STUN) to discover its public IP address when it is located behind a NAT/Firewall. When this client wants to receive an incoming connection from another party, it provides this public IP address as a possible location where it can receive a connection. If the NAT/Firewall still won't allow the two clients to connect directly, they make a connection to a server implementing Traversal Using Relay around NAT (TURN), which will relay media between the two parties.
Interactive Connectivity Establishment (ICE) is a blanket standard that describes how to coordinate STUN and TURN to make a connection between clients. Jugo uses a Network Traversal Service which implements STUN and TURN for ICE-compatible clients, such as browsers supporting the WebRTC standard.
If you are on a corporate network, virtual private network (VPN) or any network behind a firewall, you may need to speak with your IT department or network administrator to ensure your network meets the technical requirements to have the best experience with Jugo.
Jugo has created a technical test to assess if clients have the required network connectivity in place. The test determines whether clients are connected to networks that meet the necessary requirements to negotiate and establish a WebRTC media stream with Jugo.
Click here (app.jugo.io/check)
Before customers amend any network configuration, it is recommended that the technical test is performed, and the results shared with your customer services manager.
Jugo firewall rules
Jugo uses infrastructure from Amazon Web Services (AWS), Oracle Cloud (OCI) and Digital Ocean. The table below details the specific network routes needed for Jugo to operate successfully.
Jugo customers may use Network Address Translation (NAT) on their local networks where their client devices are located. Depending on the NAT type, they might have to modify the following set of rules. The provided table outlines what is needed for customers who either don't use NAT or use Endpoint-Independent Mapping and Filtering, also known as Cone NAT.
For customers using a Symmetric NAT, where clients are unable to establish a peer-to-peer connection, Jugo will fall back to using a relay server (TURN server) to provide connectivity.
- if clients are on a VPN, the network routes for Jugo listed in the table above should be allowed (whitelisted). This way, clients on the VPN can send data to the destination addresses outside of the VPN.
- Connectivity via TURN is sub-optimal, it is recommended that customers allow the necessary network routes for peer-to-peer connectivity.
- The files attached (amsterdam-ips.json, phoenix-ips.json, london-ips.json, newyork-ips.json) list the IP address ranges for the source of Jugo’s network traffic.
Jugo optimises for the best experience based on the participants’ network. The Jugo clients (WebApp and iOS app) will automatically adjust for 3/4/5G, WiFi, or wired networks.
Recommended bandwidth allowances per client:
- For 1080p HD video: 500kbps/5.0mbps (up/down)
Quality of Service (QoS) / Traffic Shaping
Customer networks may have quality of service (QoS) or traffic shaping rules applied to local network traffic.
It is recommended to set a local network policy giving priority to WebRTC traffic and categorise it as Multimedia Conferencing Service Class traffic, as defined in rfc-4594 - for applications that require real-time rate-adaptive traffic.
Some local networks may restrict external DNS lookups. Jugo clients are required to resolve the fully qualified domain names above.
Please check you can resolve these domain names using appropriate network tools (nslookup, dig) from the local network your clients will connect from. This confirms DNS lookups are not restricted on your local network.
- In case the UDP ranges are blocked, real-time communications (i.e. video/audio) will fall back to TCP which is not recommended for media transfer.
- QUIC is a protocol introduced by Google to make the web faster and more efficient. It’s on by default in Google Chrome and used by a growing list of websites. Unfortunately, most commercial/enterprise firewalls do not currently recognize QUIC traffic as ‘web’ traffic, therefore it is not inspected, logged, or reported on, leaving a hole in a network’s security. Blocking QUIC at the firewall will force the browser and server to fall back to standard HTTP or HTTPS, allowing the traffic to be inspected, protected, and reported on as usual. The advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall. Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it. More info here: https://en.wikipedia.org/wiki/QUIC and here: https://www.chromium.org/quic/.