Using South African SIP numbers in Live Kit

Getting Started
1

Hi,

Has anyone here been using Live Kit from South Africa using an SA number? I need advice with providing my Voice ISP with live kit public IP address so they can forward my SIP number to my live kit URI.

Thanks in advance.

Clifsta

2

Telephony providers like Twilio & Telynx let you purchase a South African number. Then you can connect that SA number to your Livekit agent.

Have a look at the docs for setting up SIP Trunking from these providers Provider-specific quickstarts | LiveKit Documentation

I hope that helps.

3

Thanks i did have a look. Not sure if the forwarding costs will be treated as local. But I will ask them.

Thanks again.

Cheers.

4

Your instinct about the forwarding costs is right, and I think you can avoid the problem entirely. There are two quite different architectures here and the thread has been discussing the more expensive one.

You probably do not need a second number at all

Option A (what was suggested): buy a new ZA number from Twilio or Telnyx and forward your existing number to it. Your ISP then bills you for an outgoing call leg to the Twilio number for the full duration of every call, and Twilio bills you inbound on top. You pay per minute twice, and you now maintain two numbers. That is exactly the cost concern you raised.

Option B: keep your number where it is and ask your Voice ISP to send calls for that DID directly to LiveKit’s SIP endpoint. This is IP-to-IP SIP delivery on the number you already own. There is no forwarding leg and no second number, so your ISP bills it as normal inbound termination on your existing DID at whatever rate you already pay.

If your provider sells you a SIP trunk (and “Voice ISP” suggests they do), Option B is almost certainly available. It is just a matter of them pointing origination at a different destination. Ask them: “can you deliver calls for this DID to an external SIP endpoint by hostname?” That one question decides it.

Worth knowing about Option A regardless: ZA numbers on Twilio are not click-to-buy. South Africa VOIP numbers require a Regulatory Bundle with Proof of Address, the address must fall within the geographic area matching the number prefix, and a PO Box or virtual address is not accepted. So the workaround carries its own friction.

On the public IP question

LiveKit Cloud does not hand you a single public IP for SIP. What you give your provider is a hostname:

<your-sip-subdomain>.sip.livekit.cloud

Your subdomain is your project ID with the p_ prefix stripped. Run lk project list --json, take the ProjectId field, drop p_. It is also shown on the Project settings page. Most providers accept a hostname as an origination target, and this is all they need.

If their SBC insists on IP addresses, which some older platforms do, there is a path but it comes with a trade-off. LiveKit publishes static IP ranges, but only for Canada, EU, India, Japan and US, and they apply only when you connect through the matching regional endpoint. Africa is not covered. So you would point your provider at:

<your-sip-subdomain>.eu.sip.livekit.cloud

and give them these ranges to allow and route to:

143.223.88.0/21
161.115.160.0/19
153.57.128.0/18

The cost is that your call signalling and media then hairpin South Africa to Europe and back, adding roughly 150 to 190 ms of round trip. Tolerable for some workloads, noticeable for others. Only do this if a hostname genuinely will not work on their side.

Before you go regional, ask LiveKit where a ZA call actually lands

There is a detail in the docs worth chasing before you assume you need EU pinning. LiveKit’s outbound destination_country list includes za mapped to Johannesburg, South Africa, which means there is SIP infrastructure in country. But Johannesburg is not in the list of region-pinned inbound SIP endpoints (currently eu, india, sa meaning Saudi Arabia, us, japan, aus, uk, canada).

Since the global endpoint routes each inbound call to the region closest to the provider’s endpoint, a ZA-originated INVITE may well already terminate in Johannesburg. That would be the best of both worlds: default hostname, no EU hop. Worth asking LiveKit directly, because the answer changes your architecture.

Two related notes while you are asking:

  • For the realtime side, africa is an available region group (South Africa), so your room media can stay in country.
  • Managed agent deployments are currently only us-east, eu-central and ap-south. If you are building a voice agent, the agent itself will run outside ZA regardless, and that will likely dominate your latency budget more than the SIP leg does. Worth factoring in before optimising the trunk.

What to actually send your ISP

Give them this and it should be a short conversation:

  1. Destination for calls on the DID: <your-subdomain>.sip.livekit.cloud, port 5060 UDP/TCP, or 5061 for TLS.
  2. Ask whether they can target a hostname, or require a literal IP.
  3. Ask whether they authenticate by source IP or expect digest credentials or registration. LiveKit supports IP allowlisting and username/password; it does not register to your provider.
  4. Ask for their signalling source IPs. You need these, see below.
  5. Confirm codec. G.711 A-law is the normal baseline in ZA and Europe.

What to configure on the LiveKit side

An inbound trunk plus one dispatch rule:

{
  "name": "SA inbound trunk",
  "numbers": ["+27XXXXXXXXX"],
  "allowed_addresses": ["<your ISP signalling IP or CIDR>"]
}

{
  "name": "SA dispatch rule",
  "rule": { "dispatchRuleIndividual": { "roomPrefix": "call-" } }
}

One trap that catches nearly everyone, so worth stating plainly:

  • Trunk numbers matches the called number. Your DID goes here.
  • Trunk allowed_numbers matches the calling number.
  • Dispatch rule inbound_numbers also matches the calling number.

If you put your own DID into either of the bottom two, no real caller will ever match, every call gets dropped, and your configuration will look perfectly correct in the API when you go to debug it. Leave both empty unless you specifically want to filter who can reach you.

For outbound calls presenting your ZA number, set destination_country: "za" on the outbound trunk so calls originate from Johannesburg rather than wherever your API call was made.

If you need everything in country

If your ISP will not deliver to a hostname, or regulatory or latency requirements force it, self-hosting livekit-sip on a South African VPS gives you exactly what you originally asked for: a real public IP to hand your provider, with signalling and media staying local. More operational work, but it is the only way to get a genuine ZA-terminated SIP endpoint today.