Outbound BYO SIP trunk to an Indian carrier fails with a raw TCP connect timeout

Telephony
, ,
1

Hi, running into an outbound SIP trunk issue that looks like a TCP-level blackhole to our carrier, and I’m trying to figure out how much of this is on our carrier’s side vs. something we can address from the LiveKit side.

Setup: BYO outbound trunk to Tata Tele (Smartflo) in India, dialed via sip.create_sip_participant from our agent after collecting call context. Inbound on the same account works fine. Outbound has never connected.

Trunk config (matches our carrier’s dashboard exactly Termination URI, port, and transport confirmed identical on both sides):

Outbound trunk id: ST_GQ8fyWocyxcb
Name: Outbound test 1
Termination URI/Address in outbound trunk: voice-sip.ttsl.tel:49868
Transport: TCP

Every outbound attempt fails with:

transport<TCP> dial err=dial tcp :9256->14.97.48.21:49868: connect: connection timed out
disconnectReason: SIP_TRUNK_FAILURE

This is a raw TCP connect timeout no SYN-ACK, nothing happening before any SIP signaling is attempted. We’ve confirmed via the carrier’s own call dashboard that these attempts never even register on their end, which points to the packets being dropped somewhere in transit rather than rejected by their SBC application layer.

We’ve seen this fail from multiple different source IPs across attempts (e.g. 143.223.91.185, 143.223.91.151, 143.223.94.92), all falling within the published India-region static IP ranges (143.223.88.0/21, 161.115.160.0/19, 153.57.128.0/18). Our working theory is that our carrier’s SBC firewall isn’t whitelisting this range (or isn’t whitelisting it fully.

But it could also be a setup issue in the outbound trunk config?

Three questions:

  1. Is there any way to pin outbound SIP dialing for a specific trunk to a single fixed egress IP (rather than the full regional static range), to make carrier-side whitelisting more tractable? Region pinning docs mention destination_country but I don’t see anything about narrowing egress to one IP.
  2. For everyone using BYO trunks with carriers that require strict IP whitelisting (especially outside the US/EU), what’s the common pattern — do most people front LiveKit with their own small SBC/B2BUA on a fixed IP specifically to solve this, or is there a more direct option I’m missing?
  3. Has anyone here specifically connected a BYO outbound trunk to an Indian carrier (Tata Tele/Smartflo, Airtel, etc.) and run into this same kind of TCP-timeout-at-the-firewall pattern? Curious whether this is a known integration hurdle with Indian SBCs specifically.

Happy to share more logs/call IDs if useful. Thanks!

2

Is 49868 the right port? I would have expected 5061.

I looked at one of your failing calls, SCL_9PT5JHEmizNL

Looking at the pcap, there’s just no response to the INVITE is there. Also note that it uses UDP, not your expected TCP.

No, destination_country will give you the whole India range

Yes, that is what I have seen others do. Assuming you have a strict IP whitelisting requirement, and the range cannot be whitelisted for some reason, then configure ab SBC/B2BUA as an intermediate between LiveKit and your carrier, exposing a static port. It’s worth verifying that the range can’t be whitelisted first though.

3

Thanks for looking into this!

port49868is correct, that’s what’s provisioned on Tata Tele’s (Smartflo) side for our trunk, confirmed directly on their dashboard.

that call (SCL_9PT5JHEmizNL) was from an earlier attempt where I was testing different transport methods, so UDP is expected there. Our current config is TCP throughout. For an accurate picture, SCL_h3o4KtagwyYT is the latest attempt on TCP the failure mode is the same TCP connect timeout, no response, consistent with the earlier pcap finding.

Given that, and your confirmation that destination_country can’t narrow the egress to a single IP, I’m going to treat this as an IP whitelisting issue on the carrier’s side and follow up with Tata to get LiveKit’s static range whitelisted (or move to an SBC in front if that’s not workable on their end, per your suggestion).

Appreciate the help will report back here if it turns out to be something else, in case it’s useful for others hitting the same thing with Tata/Indian carriers.