Fixed source port needed for outbound SIP trunk

Getting Started
1

We have an outbound SIP trunk configured on our project , pointed at our SIP provider at 212.125.8.150:5060 (UDP).

Our provider’s firewall/SBC is rejecting our SIP INVITEs. We asked them to check their SBC logs (sngrep), and they confirmed the packet trace directly:

INVITE 9021657…@2nq9nvr76mc. → +90535273....@212.125.8.1…
Source: 143.223.92.188:9000 → Destination: 10.10.20.210:5060
Call State: REJECTED

Other calls in the same capture window — from different source IP:port pairs, all on port 5060 — show IN CALL / COMPLETED. So their SBC is specifically rejecting traffic that doesn’t arrive on port 5060.

Separately, across test calls earlier the same day, our INVITEs came from three different source IPs: 143.223.92.8, 143.223.92.11, 161.115.161.104 — all sent to 212.125.8.150:5060, all with source port 9000, none
acknowledged (not even 100 Trying) before timing out at ~32s.

Since our provider enforces port-based filtering rather than accepting arbitrary sources, we need to ask:

  • Does LiveKit Cloud support a fixed source port (e.g. 5060) for outbound SIP trunk signaling, instead of the current 9000?
  • Does it support a static/dedicated source IP for outbound SIP trunks, given ours varied across three addresses in one day?
  • If neither can be pinned on our end, could you tell us the full range of source IPs/ports we should ask our provider to whitelist instead?
2

Hi, regarding the IP addresses, we list the range of IPs here: Configuring firewalls | LiveKit Documentation . You didn’t mention which country this is happening in, but all the IP addresses fit within one of the stated ranges.

Regarding the source port, 9000 should be a valid value and there is no way to modify this. Did the provider say this was the reason the call was being rejected?

Can you share a call ID for one of the failing calls? (starting SCL_) There might be some more clues in the pcap I can see.

3

Here’s a call ID for one of the failing attempts: SCL_v7XaB5CFwy4K @darryncampbell

4

Thanks, looking at the PCAP, it does show the provider responding to the invite. The 407 is expected as it is asking for authentication, then the 403 indicates this is an authorization error.

none
acknowledged (not even 100 Trying) before timing out at ~32s.

^ that must be a separate issue, since in the call you shared it is at least responding.

To me, the question is what is triggering the 403 and the best place to start looking would be trunk configuration.