> For the complete documentation index, see [llms.txt](https://help.dscout.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.dscout.com/interview-studies/what-are-interview-studies-in-dscout/configure-your-network-for-interview-sessions.md). # Configure your network for interview sessions {% hint style="info" %} This document provides the necessary guidance to configure your network to support Dscout interview sessions. We suggest working with your internal IT team or network personnel to complete this configuration. If you have any questions, reach out to Dscout support. {% endhint %} 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](https://www.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**](https://developer.liveswitch.io/liveswitch-server/guides/what-are-stun-turn-and-ice.html)**):** 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. {% hint style="info" %} Daily.co relies on Twilio TURN and STUN servers. While Twilio plans to sunset their video product, they do not plan to sunset their TURN and STUN servers. {% endhint %} ## Testing and troubleshooting Please run [Daily’s network test](https://network-test.daily.co/) 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 {% hint style="warning" %} Inspection proxies that decrypt and re-encrypt traffic are known to break WebRTC. You will need to make an exception for TURN, STUN, and ICE traffic so it is not inspected. Additionally, various Data Loss Prevention (DLP) applications (for example, Netskope and Cloudflare Zero Trust) that are common in enterprise IT can also disrupt interview sessions. {% endhint %} 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. {% stepper %} {% step %} #### Direct connection to SFU over UDP 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. {% endstep %} {% step %} #### TURN over TCP/UDP on port 3478 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. {% endstep %} {% step %} #### TURN over TLS on TCP/443 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. {% endstep %} {% step %} #### Company-owned TURN servers 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. {% endstep %} {% endstepper %} ## Other resources * [Daily firewall traversal guide](https://docs.daily.co/private/firewall-traversal-guide). * [Daily network test](https://network-test.daily.co/index.html). * [Twilio networking considerations](https://www.twilio.com/docs/video/networking-considerations). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.dscout.com/interview-studies/what-are-interview-studies-in-dscout/configure-your-network-for-interview-sessions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.