Configure your network for interview sessions

Interview sessions combines video conferencing with a suite of research-focused tools to make remote interviewing seamless and efficient for your users. A typical session includes one researcher (a member of your organization) as well as a participant (the person being interviewed).

The video conferencing functionality of Dscout's interview sessions is powered by Daily.co, a WebRTC vendor. Since researchers will connect to each session using your network, you'll need to ensure your firewall and network are configured to allow access to Daily.

Definitions

WebRTC terminology

• STUN (Session Traversal Utilities for NAT): Used to establish a direct UDP connection between two clients.
• TURN (Traversal Using Relay around NAT): Used to establish a relayed UDP or TCP connection between two clients. Here, the traffic must be relayed through the TURN server to bypass restrictive firewall rules, and the preference is UDP over TCP because TCP's guaranteed ordered delivery of packets implies overhead that is undesirable for real-time communications.
• TURNS (Secure Traversal Using Relay around NAT): Used to establish a relayed TCP/TLS connection between two clients. Here, the traffic must be relayed through the TURN server and through a TLS socket to bypass extremely restrictive firewall rules.
• ICE (Interactive Connectivity Establishment): A standard for using STUN and TURN to establish connectivity between two endpoints. ICE takes all of the complexity implied in the discussion above, and coordinates the management of STUN, TURN, and TURNS to a) optimize the likelihood of connection establishment, and b) ensure that precedence is given to preferred network communication protocols.
• SFU (Selective Forwarding Unit): An SFU is a media server component capable of receiving multiple media streams and then deciding which of these media streams should be sent to which participants. Its main use is in supporting group calls and live streaming/broadcast scenarios.

Testing and troubleshooting

Please run Daily’s network test to see if your network configuration allows for Daily to function. It will test all possible connection methods and indicate what is and isn’t working.

Please make sure to run this test from the same network segment (or VPN) your Researchers will be using.

Daily network resources

Each section below describes a stage in establishing a WebRTC call. They are arranged roughly in the order they happen when a new call is established, and each stage must work for the call to work overall. Each stage further outlines multiple options, in order of preference, for making that particular stage work.

Daily resources

These are Daily specific resources that must always work:

• b.daily.co and c.daily.co must be reachable on TCP/443. Daily SDKs pull in various resources at runtime that aren’t included in SDKs.
• dscout.daily.co must be reachable on TCP/443. Used for various in-meeting communication.

Call initiation

The following must be reachable for call initiation to work:

• gs.daily.co must be reachable on TCP/443. This is a dispatch server that helps identify which location to use to connect the call.
• prod-ks.pluot.blue must be reachable on TCP/443. This is a Daily-owned server used for ICE negotiation.
• Twilio STUN *.stun.twilio.com must be reachable on TCP/UDP/3478 or TCP/443.

Signaling

In WebRTC, signaling is what establishes the initial connection for a call.

Daily uses its own SFUs for signaling. For this to work, *.wss.daily.co should be reachable on TCP/443. Clients use a WSS (Secure WebSockets) connection with SFUs.

Media streaming

This is how the actual media streams get to and from all call participants.

1. The ideal option is a direct connection to SFU over UDP. This provides the lowest latency for call participants. Clients need to connect to *.wss.daily.co over TCP/443 and UDP/40000-65534 for media streaming. This allows Daily to work without relying on TURN servers and is the preferred solution.
2. The next best option is to use TURN over TCP/UDP on port 3478 via Twilio servers *.turn.twilio.com. This option adds less than 50ms of latency because the media stream has to relay through TURN. It’s not ideal, but it is often not too noticeable to call participants.
3. The least user-friendly option is TURN over TLS on TCP/443 via Twilio servers *.turn.twilio.com. This is the least preferable option because it adds more than 50ms of latency, which causes noticeable lag for the audio and video experience due to the extra overhead of TCP and TLS.
4. Some companies run their own network of TURN servers. If your company has its own, please contact Dscout support to see if traffic can be routed through your TURN servers.

Other resources

• Daily firewall traversal guide.
• Daily network test.
• Twilio networking considerations.