One direction call only - URGENT

[Manav_Kulshrestha]

We are facing an RTP media IP mismatch issue with our CPaaS provider in India.
We had previously whitelisted the following LiveKit IP ranges on the CPaaS side:

• 143.223.88.0/28

• 161.115.160.0/28

However, we are now observing RTP/media traffic originating from a different IP range (e.g., 143.223.94.x). Our CPaaS provider is refusing to open the SIP trunk for all IPs and requires the exact static IP ranges used by LiveKit for SIP and RTP media.

They have confirmed that SIP signaling is working, but media is being blocked due to the unexpected IP range. They suspect firewall restrictions on their side, but need us to provide the authoritative IP ranges used by LiveKit for SIP trunking and RTP.
Could you please clarify:

1. The complete and fixed IP ranges used by LiveKit for SIP trunking and RTP media.

2. Whether LiveKit uses dynamic IP allocation for RTP/media and if so, how to restrict it to static IP blocks.

3. Any recommended best practices for CPaaS providers that require strict IP whitelisting.

This is a blocker for production deployment, so an exact and definitive answer would be very helpful.

[darryncampbell (Darryn)]

Hi, our list of static IPs are here: Configuring firewalls | LiveKit Documentation

For India, the blocks are 143.223.88.0/21 161.115.160.0/19, which match the ranges you have already whitelisted.

Since 143.223.94.x falls within 143.223.88.0/21 this is expected behaviour, so I’m confused why the traffic is rejected due to an unexpected IP range. I assume you are also already pinning your SIP traffic for India, as detailed here: Region pinning for telephony | LiveKit Documentation

[Manav_Kulshrestha]

We have a screenshot, can you guide us what we might be missing? This is visible to our Indian Cpaas

[darryncampbell (Darryn)]

The SIP invite looks good to me and it looks like a successful leg doesn’t it? LiveKit is answering the call, media is being exchanged, and then the remote end terminates the call after 10 seconds or so.

[Manav_Kulshrestha]

Actually, when we are on the phone, we are hearing silence. Looks like RTP is only one side. We are able to speak, but cannot hear anything.

[darryncampbell (Darryn)]

Got it, hence the topic name!

If you look at the PCAP for the session you sent the screenshot of above, do you see RTP traffic going in both directions?

Might also be a good idea to look at the agent observability recordings to determine if the agent was able to hear your audio.

[Manav_Kulshrestha]

Let me share the PCAP with you shortly. Agent is able to hear what we say, and we are getting transcripts for the same.

[Manav_Kulshrestha]

call_filtered.pcap (442.7 KB)

Can you help us understand what might be the issue here or what are we missing out? the audio silence is the problem. Attached PCAP for your reference.

[CWilson]

In that PCAP you can see the RTP is traveling in both direction so not sure why the caller is not hearing it. When I have seen this in the past it has always been a firewall issue on the SIP provider side or a proxy that sits between.

[Manav_Kulshrestha]

Is it possible that turn domains and livekit hostnames are not whitelisted but only static IPs are whitelisted being the reason for audio not being heard?

For Example below hostnames and +15 others not whitelisted? :

<your-subdomain>.ohyderabad1a.production.livekit.cloud	TCP 443
<your-subdomain>.ohyderabad1b.production.livekit.cloud	TCP 443

ohyderabad1a.turn.livekit.cloud	TCP 443
ohyderabad1b.turn.livekit.cloud	TCP 443

[CWilson]

it would not be port 443.

[Manav_Kulshrestha]

Configuring firewalls | LiveKit Documentation

Picked these straight from this page.

[CWilson]

The PCAP you sent is not using port 443,

Do you have a NAT or SBC/media proxy between the phone endpoint and LiveKit

[Manav_Kulshrestha]

Our agents are deployed to render.com if that helps, or i can ask the cpaas for this.

[CWilson]

The issue is not the agent or LiveKit side. This is audio not getting passed by the CPaaS.

I suspect they allow listed /28 instead of /21 and /19

Look at the PCAP you sent and it will be clear

[Manav_Kulshrestha]

@CWilson

/28 ins

As per them they have whitelisted this.

[CWilson]

Why are they not relaying the audio to the caller?

[Manav_Kulshrestha]

You mean NAT is disabled?

[CWilson]

no, I mean why is the CPaaS not playing the audio we are sending.

[CWilson]

Looks like the problem is there is a Asterisk in the middle blocking traffic form CPaas to LiveKit and LiveKit to SPaaS. You will need to talk to whoever is running the Asterisk.