SIP: static IP ranges for inbound, and carrier registration support

Telephony
, ,
1

I’m on LiveKit Cloud (Build plan) with a Malaysian carrier that uses SIP registration. Their system only routes inbound calls to a registered endpoint, and they’ve confirmed no registration exists — which makes sense, since LiveKit Cloud doesn’t register to carriers.

They’ve offered static routing instead, but need a destination. My project endpoint xxxxx.sip.livekit.cloud resolves to a single A record with a 10-second TTL, so it doesn’t look like a stable target for a carrier’s routing table.

Two questions:

  1. Are there published IP ranges for LiveKit Cloud’s inbound SIP endpoints that a carrier can route to, or is the hostname the intended target?
  2. Does LiveKit Cloud support outbound SIP trunks registering to a carrier? If so, that would solve this directly.

Outbound already works fine through this carrier — it’s only inbound that has nowhere to land.

2

No registration, either direction livekit/sip only handles OPTIONS/INVITE/ACK/BYE/NOTIFY (server.go (sip/pkg/sip/server.go at main · livekit/sip · GitHub)), so REGISTER falls to OnNoRoute and 405s (#338 (Auth credentials not honored on Livekit Cloud · Issue #338 · livekit/sip · GitHub)). Static routing is your only path.

And the ranges do cover you the firewall docs Configuring firewalls | LiveKit Documentation) scope static IPs to “realtime, SIP signaling and media”, so give the carrier 143.223.88.0/21, 161.115.160.0/19, 153.57.128.0/18 instead of the A record. Just get the project pinned to Japan first:

asia is Japan + Singapore, and only Japan sits inside those ranges.

3

I have seen customers also solve this by adding a SIP proxy such as Kamailio or Asterisk in-between LiveKit and your carrier.

4

Thanks — for inbound I’m actually using the region-based SIP endpoint ({subdomain}.india.sip.livekit.cloud), not the asia realtime region group. The telephony region-pinning docs list india and japan as separate entries there, so I think this sidesteps the Japan/Singapore ambiguity you flagged — does that match your understanding, or is there a reason SIP region-based endpoints would still land outside the India static IP range?

Also confirmed there’s no REGISTER support either direction, which matches what myvoip found on their end — appreciate you pointing to the source. Static routing to the India endpoint is what we’ve set up.

One more thing while I have you — for outbound calls, the docs mention destination_country on the trunk to pin the origin region, separate from the inbound SIP endpoint. Is that the right lever for consistent outbound latency, or does it interact with the India inbound pinning in a way I should know about?

5

@Horng_Yarng_Tan That matches my understanding, yes and it’s a useful distinction worth spelling out, because the two are separate axes. What I described earlier was realtime region pinning, where asia is a group spanning Japan and Singapore. SIP region endpoints are their own thing: the region pinning docs give {sip_subdomain}.{region_name}.sip.livekit.cloud with aus, eu, india, japan, sa, uk, us each listed individually, so india is explicit and the group ambiguity doesn’t arise for you.

India is covered by the static ranges the firewall docs scope them to Canada, EU, India, Japan and US. One thing worth knowing for anyone else reading: those two lists aren’t 1:1. aus, sa and uk are valid SIP regions with no static IP coverage, so a project pinned there would still be back to the hostname problem.

Before the carrier commits the route, I’d confirm your own endpoint rather than trusting the region name:

dig +short <your-subdomain>.india.sip.livekit.cloud

and check the result falls inside 143.223.88.0/21, 161.115.160.0/19 or 153.57.128.0/18. Mentioning it because the bare region hostnames aren’t a reliable proxy india. and japan. both resolve to the same address here, as do us. and eu., so only your project’s own host tells you where it actually lands.

On destination_country that’s the right lever, and it doesn’t interact with your inbound pinning. The docs say “when destination_country is set, outbound calls originate from a server within the specified country”, it applies to outbound trunks only, and inbound region configuration is independent of it.If a country code has no regional support, the parameter has no effect and calls fall back to default routing rather than erroring, so
it’s worth confirming MY actually takes rather than assuming it did.