Static IP confirmation for India-region SIP trunk (carrier firewall requirement)

We’re setting up an inbound SIP trunk to receive calls from a telephony carrier (Ozonotel, India-based) who requires TLS-only signaling and needs to configure firewall rules against fixed RTP/media IPs and a fixed port range on their side. A few things we need confirmed before we hand these values to the carrier:

  1. Region pinning: Does our project need to be explicitly pinned to the India region (via a dashboard/API setting) for the static IP ranges to reliably apply, or is connecting through the regional endpoint (<project_id>.india.sip.livekit.cloud) sufficient on its own? If pinning is required, how do we set/verify it for this project?
  2. Static IP ranges: Can you confirm the exact CIDR ranges for SIP signaling and RTP media traffic specific to the India region? Your public docs list 143.223.88.0/21, 161.115.160.0/19, 153.57.128.0/18 — we want to confirm these are correct and India-specific (they appear identical across other regions in the docs table, so we want to rule out a documentation error before sharing them with a carrier).
  3. RTP/media port range: What UDP port range does the India-pinned cluster use for SIP trunk media specifically? (We’ve seen 50000–60000 referenced for a Japan-pinned project in a community thread — want to confirm whether that’s the same range for India, or if SIP-originated media uses a different range than WebRTC/room media.)
  4. TLS SIP URI format: Please confirm the exact SIP URI our carrier should dial for TLS — is sip:{project_id}.india.sip.livekit.cloud;transport=tls correct, or is a sips: scheme / explicit port 5061 preferred/required on your end?
  5. SRTP: Is media encryption (SRTP) available by default on India-region inbound trunks, or does it need to be explicitly requested/enabled for this project?

@Developer The identical CIDRs across regions are by design, not a documentation error, so those three blocks are the right values to give Ozonotel for India. On your five points:

  1. Region pinning: the static blocks apply in any covered region, and India is covered, so the IPs are valid whether or not you pin. Connecting through {subdomain}.india.sip.livekit.cloud is what selects India for signaling and media (regions & static IPs). For explicit project-level enforcement, use the region-pinning setting (region pinning). One caveat from the static-IP page: outside covered regions, traffic egresses from cluster IPs that are not part of the static guarantee, so keep the carrier pointed at the regional endpoint.

  2. Static IPs: the table lists the same 143.223.88.0/21, 161.115.160.0/19, 153.57.128.0/18 for every covered region including India, because they are LiveKit’s shared static egress blocks, not per-region-unique values (same page). Correct for India.

  3. Media port range: the docs show UDP 50000-60000, but that entry is labeled WebRTC media on the corporate-firewall page (firewall), not the SIP-trunk RTP range specifically. I would not hand a carrier that range for SIP media without confirmation. Get the exact SIP signaling port (5061 for TLS) and the SIP RTP media UDP range for India from LiveKit support before giving it to Ozonotel.

  4. TLS SIP URI: sip:{project_id}.india.sip.livekit.cloud;transport=tls is correct. Use the sip: scheme with ;transport=tls appended, not sips: (secure trunking). If the carrier cannot send URI parameters, enable TLS in the trunk settings and use port 5061, the default for SIP over TLS. TLS must be enabled on the trunk either way.

  5. SRTP: not on by default. Enable it on the inbound trunk with mediaEncryption set to SIP_MEDIA_ENCRYPT_ALLOW (use if available) or SIP_MEDIA_ENCRYPT_REQUIRE (require), or per call (same page). So it has to be requested explicitly for this trunk.