Dscout Live, our moderated research tool, combines video conferencing with a suite of research-focused tools to make remote interviewing seamless and efficient for your users. A typical Live session includes one or more Researcher (a member of your organization) as well as a participant (the person being interviewed).

The video conferencing functionality of Dscout Live is powered by Daily.co, a WebRTC vendor. And since Researchers will connect to each Live session using your network, you'll need to ensure your Firewall and network are configured to allow access to Daily.

Contents

• Definitions.
• Testing and troubleshooting.
• Daily network resources.
• Other resources.

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 to identify which location to use to connect the call to.
• 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 WSS (Secure WebSockets) connection with SFUs.

Media streaming

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

1. The ideal option is a direct connection to SFU over UDP. This provides the smallest latency / lag 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 media stream has to relay thru TURN. It’s not ideal, but 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/video experience due to extra overhead of TCP and TLS.
4. Some companies run their own network of TURN servers. If your company has your own, please contact Dscout support to see if we can route traffic through your TURN servers.

Other resources

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