We’ve just finished a PoC on LiveKit Cloud for our video conferencing product and are preparing to move it into
production. We’re on Build today and will upgrade to Scale. Our users are all in South Korea, so we plan to request
region pinning.
We’re now at the stage of getting corporate firewalls opened, both on our own network and at enterprise customers
with strict egress allowlists. Those requests take time and are hard to revise later, so I’d like to get the details
right first. Three questions I couldn’t resolve from the docs.
Can UDP 50000-60000 and TCP 7881 be scoped to the three static IP ranges?
The firewall page lists these two rows as all hosts (recommended), while the other rows name hostnames. Asking a
security team to open a 10,000-port UDP range to any destination is not something we can get approved, so we’d like
to publish 143.223.88.0/21, 161.115.160.0/19, 153.57.128.0/18 instead. Is media traffic guaranteed to stay inside
those ranges, or is all hosts genuinely required?
Do the three static ranges also cover TCP 443?
The docs describe the ranges as covering “Realtime, SIP signalling and media, Webhooks” but don’t map them to ports.
If signalling and TURN/TLS are inside those ranges as well, customers could open 3 ranges × 5 ports and skip domain
rules entirely.
What does the asia region actually include, and how does it relate to the static IP page?
The region pinning page lists selectable regions as groups — us, asia, eu, and so on — while the static IP page lists
Canada, EU, India, Japan and US. Since there’s no Japan-level option, I’d like to understand what pinning to asia
covers: which locations can serve media, and whether the “Japan” ranges on the static IP page are the right ones to
publish for an asia-pinned project. All our users are in Korea, so latency to the serving location matters to us as
well.
Yes, the ranges listed at Configuring firewalls | LiveKit Documentation will apply to UDP and TCP. These are covered under the Realtime bullet listed as ‘Static IPs apply to the following services’. Media will stay within these ranges.
Yes, they do.
The ‘asia’ region, as detailed under Region pinning | LiveKit Documentation covers Japan and Singapore and includes in-region redundancy, i.e. if our Japan node goes down, traffic is automatically rerouted to Singapore. The static IP addresses only apply to Japan. It is possible to region pin to Japan specifically, but then you would lose your in-region redundancy and this is a trade-off that our support team can explain in more detail when you enable your region pinning.
In general, LiveKit cloud does a great job at connecting users in a way that minimises latency - if your only goal was to reduce latency I would say that region pinning was unnecessary. Since however you require the static IP blocks, and we only offer those blocks in specific regions, in your case it makes sense.
One follow-up at the zone level. Japan is listed as a static-IP region, and its zones resolve like this:
otokyo1a 161.115.166.94 161.115.166.128 inside the ranges
otokyo1b 152.70.96.56 158.179.181.56 outside
otokyo1b.turn.livekit.cloud resolves to the same addresses, and our project’s regions endpoint lists otokyo1b as the
third-nearest candidate for clients in Korea.
Two questions:
Can a project be served by a zone whose addresses sit outside the published ranges — with or without Japan
pinning?
If so, what would you recommend we give customers as the allowlist? Firewall capabilities vary quite a bit across
our customers, so we’d like to describe something that holds in every case.
If we pin your project to Japan it would not be served by otokyo1b, so your pinned project would indeed be subject to the known static IPs.
This isn’t clear from the docs, so we will get those updated.
So, to answer your questions:
Can a project be served by a zone whose addresses sit outside the published ranges — with or without Japan pinning?
The intention is that when pinned to a zone a project will sit inside the published ranges.
If so, what would you recommend we give customers as the allowlist? Firewall capabilities vary quite a bit across our customers, so we’d like to describe something that holds in every case.
I would still be mindful that you are giving up regional failover. If it were me in your position, I might have one (pinned) project for customers who have tight firewall requirements, and another (unpinned) project that lacks static IP but does offer regional failover. There would of course be a cost implication to having two projects, but probably worth discussing with support when the project is pinned.
Thank you for the clarification on Japan pinning and otokyo1b - that answered our main concern, and it is good to hear the docs will be updated.
One more thing we would like to confirm before we rely on it. We have found a possible manual failover path.
What we tested
Using our unpinned test project, we pointed the client at {subdomain}.india.rtc.livekit.cloud. Everything the session used stayed within your published static IP ranges: the signalling host, the ICE media candidate (143.223.94.82:50008), and the TURN server it offered (ohyderabad1a.turn.livekit.cloud).
What we want to do
Pin the project to Japan. If Japan goes down and regional failover is unavailable, manually switch the LiveKit server
URL our backend hands out to another region that has static IPs (india, eu, canada, etc.). We accept losing automatic regional failover in exchange for the static IP guarantee.
The allowlist we hand to customers uses wildcard domains together with your three static IP ranges,
so switching to a regional hostname needs no change on their side.
We did look at the two-project setup you suggested. Splitting traffic would mean routing per customer workspace, which we cannot support operationally, so we need a single project to work for both cases.
Three questions
Our test project is not pinned. On a project pinned to Japan, does a regional entry URL still take effect, or does the pin override it and keep the session in Japan?
Is the in-range result deterministic? India also contains zones outside the static IP ranges - we measured omumbai1b as outside. Could a session land on one of those, or does the regional entry point exclude out-of-range zones the same way Japan pinning excludes otokyo1b?
Would this still work while Japan is down? Our test ran with Japan healthy, and routing behaviour under a regional outage may differ.
Apologies for the repeated questions. The static IP guarantee is a hard requirement for several of our enterprise
customers, so we need this settled before we migrate.
The problem with this though, is the project is part of the LiveKit server URL used by your clients to connect, so all your clients would have to connect to a different project during a “manual switch”. (It couldn’t reuse the same project that is pinned to Japan)
I’m assuming just pinning to India is not acceptable from a latency perspective, since doing that would solve all these issues. I’m not sure how you are measuring the Indian endpoint as outside the static IP range, that should not be the case.