in a multiregion sfu deployment (selfhosted), lets say the the first user joins from region x, and the other persons got redirected to region y via cloudflare load balancer. Ive region awareness on for my sfus, so does the other person gets redirected to region x (bc the room is there) or the media proxies through region y for the other user

Thanks for reaching out, Punit. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

yeah go ahead. also does this mean I pay double egress costs bc media is now getting exited twice in this scenario

Thanks — I’ll explain two things: how inter‑region media relaying affects latency/traffic, and how billing works. Latency/traffic • When the room is anchored in Region X but a participant connects to Region Y, Region Y’s SFU stays the participant’s local gateway and relays media to/from Region X. Clients are not redirected. • That relay adds an extra network hop between SFUs, which can increase end‑to‑end latency for cross‑region streams and adds inter‑region bandwidth use on your private backbone. • To reduce latency you can: ◦ Prefer routing participants to the room’s region (region pinning or LB rules) so fewer cross‑region relays are needed. ◦ Use nearby SFU edges for participants whenever possible so relays take the lowest‑latency paths. Costs / egress billing • You do not pay “double” egress for internal SFU‑to‑SFU relays. Billing is for the final leg of media delivered to end users (downstream/egress to participants) and upstream from publishers — internal SFU relay traffic is not billed as egress. • Practically: you’re billed for the bandwidth each participant downloads (and uploads) to their client, not for the internal cross‑region hops between SFUs. If you want, I can: • Suggest specific load‑balancer rules or Cloudflare config to favor the room’s region, or • Walk through an example cost/ bandwidth calculation for your expected participant distribution. Which would you like next? Sources: A Tale of Two Protocols: WebRTC vs. HLS for Live Streaming | How We Built a Globally Distributed WebRTC Mesh Network | livekit/livekit_composite | DeepWiki | The end of Participant Minute pricing | Data Processing Addendum | LiveKit

is there any benifit that the second user is connected to region Y as compared to if they were directily connected to region x

Good question — short answer: yes, there can be benefits and trade‑offs. Benefits of connecting the second user to Region Y • Lower client‑to‑edge latency and better upload quality if Region Y is geographically or network‑closer to that user. • Better user experience on constrained networks (fewer client retransmits, smoother capture). • Load distribution: spreads publisher/encoder load across SFUs, helping scale and avoid hot spots. • Fault isolation: if Region X has issues, Region Y can continue relaying or host new participants. Trade‑offs vs connecting directly to Region X • Slightly higher end‑to‑end latency for cross‑region subscribers because media is relayed between SFUs. • Additional inter‑region backbone traffic (not billed as egress, but still consumes network capacity). • Potentially more complex routing behavior (dynamic relay decisions). When to prefer Region Y for that user • The user’s RTT to Region Y is meaningfully lower than to Region X. • You want to reduce client upload problems or balance load across regions. • You prioritize local reliability or compliance. When to prefer routing them to Region X • You need the absolute lowest end‑to‑end latency between that user and participants already in Region X. • You want to avoid any additional cross‑region hops (e.g., for very latency‑sensitive apps). If helpful, I can: • Run a simple decision checklist for your app (latency sensitivity, user distribution, bandwidth limits), or • Suggest Cloudflare/load‑balancer rules to favor region pinning or proximity. Which would you prefer?

for my usecase, there is one person streaming into the room. I keep the ingress closest to the streamer + ingress closest to the primary SFU as well where the room is hosted. Now users can join from all across the world, and I have SFUs there as well. Currently in AU and US central. I am trying to figure how livekit will behave in this scenario

Thanks — I’ll explain how LiveKit will behave for your setup (one streamer with ingress near them + primary SFU hosting the room, viewers worldwide with SFUs in AU and US‑Central), and give practical recommendations. How media is routed • The room control remains anchored at the primary SFU (where you host the room). • The streamer publishes to their nearest ingress; that SFU will forward the published tracks to the room’s primary SFU if it’s in a different region. • Viewers connect to their nearest SFU (AU or US‑Central). Those edge SFUs subscribe to the streamer’s tracks by fetching/relaying them from the SFU that currently holds the source (the streamer’s SFU or primary SFU). • Clients are not redirected client‑side — each viewer stays connected to their local SFU, and SFUs relay media between regions as needed. Latency and quality implications • Viewers geographically near their local SFU get low client↔️edge latency and better upload reliability. • Cross‑region viewers incur one extra SFU↔️SFU hop for media between the streamer’s SFU/primary SFU and their local SFU — this increases end‑to‑end latency compared to everyone connecting to the same region. • The extra hop can also slightly increase jitter/loss risk for those specific streams, but the relay is UDP/RTP‑based and optimized for real‑time forwarding. Bandwidth / cost • You are billed for upstream from the publisher and downstream to each viewer. Internal SFU→SFU relay traffic is not billed as egress. • Total billed egress equals the sum of what each viewer downloads (plus publisher upload). Cross‑region relays do not double‑bill. Recommendations • Keep the streamer’s ingress in the region closest to the streamer (you already do) to minimize their upload latency and capture quality. • If most viewers are concentrated in one region, consider hosting the primary room there to reduce total relay hops. • If viewers are truly global, keep regional SFUs (AU and US‑Central). This optimizes client experience since viewers connect to nearby edges and SFUs handle relay. • If ultra‑low end‑to‑end latency to the streamer is critical for some viewers, use load‑balancer rules or region pinning to route those viewers to the streamer’s region. • Monitor per‑region metrics (RTT, packet loss, bitrate) and adjust routing or add edges where needed. If you want, I can: • Sketch a simple traffic/egress cost example based on expected viewer counts and bitrates, or • Suggest Cloudflare/LB rules to prefer the streamer’s region for specific viewer sets. Which would you like next?

• Suggest Cloudflare/LB rules to prefer the streamer’s region for specific viewer sets.

I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!