Introduction
Daily’s WebRTC calls use a signaling server to manage call state in both Peer-to-Peer (P2P) and Selective Forwarding Unit (SFU) modes. Additionally, in SFU mode, this server also sends and receives the audio and video data from each participant.
At Daily, a single server functions as both a signaling server and an SFU in the given region. In this post, we'll refer to this as the "call server".
Our call servers can be located in several geographic regions. You can check out a full list of our available regions in our domain configuration documentation. The same geo
property is also available at the room configuration level.
Daily previously had an EU server location in London ("eu-west-2"
). However, now that London is no longer a location within the EU, we needed another EU-based region. Now, we are pleased to say that we have added the "eu-central-1"
region located in Frankfurt, Germany to our selection.
Server location can have an impact on latency experienced by call participants, and having an SFU available in Frankfurt can give room and domain owners further control to optimize their participants' call experience.
Let's go through what we mean when we talk about signaling servers and SFUs in a little bit more detail.
What is a signaling server?
A signaling server is a server which essentially helps two devices find each other and establish a Peer-to-Peer connection. Even in P2P mode, which requires no central server for the actual WebRTC data transfer to take place, a signaling server is used to help devices discover each other. A signaling server acts as an intermediary between two peers. At Daily, these servers keep track of who is in a call, who’s left a call, and other relevant call state information.
What is an SFU?
A Selective Forwarding Unit (SFU) is a server which receives all participants' video and audio tracks and forwards them to relevant call participants.
With Daily, a signaling server can also act as an SFU. Calls start out in P2P mode. This means the signaling server is used only to establish Peer-to-Peer connections with other participants and keep some relevant call state. If the call participant count goes over 4, the call is seamlessly switched to SFU mode. At this point, our signaling server also acts as an SFU, sending audio and video data between participants as needed.
Aside from this default behavior, developers can also manually toggle SFU or P2P mode in Daily calls via our API's setNetworkTopology()
method. For most applications, letting Daily handle these states is going to be the most efficient option. If you're not sure if your use case calls for manual toggling between SFU and P2P modes, please reach out and we'll be happy to advise.
If you'd like more details, check out our guide on Daily's WebRTC video call architecture.
So what does this have to do with server regions?
Signaling server location effects on WebRTC call performance
By default, Daily picks which call server to use based on the location of the participant who joined the call first. If the first participant joins from Oregon, a signaling server in the "us-west-2"
region will be selected. This means if the rest of the participants join from the EU, they may experience more latency than is ideal for their region.
Therefore, if you know that most call participants will be joining from Europe, it may be worth considering manually configuring the given room to be hosted using a server in the "eu-central-1"
region. You can do so by specifying the geo
property at the room or domain level.
Does this mean customer data stays within the EU?
In short: not yet, but stay tuned!
We've occasionally gotten enquiries about SFU server locations as they pertain to transferring call participant data outside of the EU, specifically in relation to GDPR.
While EU privacy legalities are beyond the scope of this post, some customers would like the option to keep call participant data within EU borders. The new "eu-central-1"
region is a step in this direction, but calls powered by Daily still rely on some US-based services. We're aiming to have more news to share on this front in the second half of the year; you can sign up for our newsletter below for updates when the time comes.
In the meantime, please contact us if you have any questions about our server locations or associated configuration options.