Thanks — I see you need to whitelist IPs for outbound SIP to work with Exotel. Quick facts: • LiveKit Cloud does not provide static IP addresses for SIP traffic, so you cannot supply fixed IPs for Exotel to whitelist. • Use SIP username/password (credential-based) authentication for your outbound trunk. • If Exotel requires IP-based filtering anyway, you can ask them to allow the full public range (

0.0.0.0/0

). LiveKit recommends this when static IPs are not available. To move forward, please tell me: 1. Are you configuring the trunk now in LiveKit or already configured it in Exotel? 2. Does Exotel allow credential-based auth (username/password or SIP digest) or only static-IP whitelisting? If you want, I can provide the exact LiveKit docs link and the recommended config steps for credential auth. Sources: SIP outbound trunk | LiveKit docs | SIP overview | LiveKit docs

Thanks — I reviewed the log and config you shared. What the log shows • The error means LiveKit attempted an SRV DNS lookup for _sip._udp.pstn.in2.exotel.com and failed to resolve it, so the target host couldn't be resolved/reached. Immediate checks to run 1. Confirm the trunk

address

matches the exact host Exotel expects. Your config shows

<http://sbc.exotel.com|sbc.exotel.com>

— keep that (do not use raw IP) unless Exotel tells you a different FQDN. 2. Ask Exotel whether inbound SIP to them requires SRV records (the lookup in the log is an SRV for _sip._udp...). If they do not publish SRV, LiveKit will try A/AAAA — Exotel should confirm supported hostnames and transports. 3. Have Exotel verify they have explicitly allowlisted the calling FQDN

5njt9qbiof7.sip.livekit.cloud

and that it will accept connections to their SBC (

<http://sbc.exotel.com|sbc.exotel.com>

) from LiveKit. 4. Provide Exotel a sample timestamp when you attempt a call and ask them to check for incoming INVITEs or blocked DNS/SIP attempts at that time. Useful tests (if you can run or ask Exotel to run) • From a network that mirrors LiveKit egress, run: ◦ dig SRV _sip._udp.pstn.in2.exotel.com ◦ dig A/AAAA sbc.exotel.com ◦ nc -v -u sbc.exotel.com 5060 (UDP) and nc -v sbc.exotel.com 5060 (TCP) to test reachability • Ask Exotel whether

<http://pstn.in2.exotel.com|pstn.in2.exotel.com>

is an alias that requires SRV or if

<http://sbc.exotel.com|sbc.exotel.com>

is the canonical SBC hostname. Config guidance for LiveKit • Use

address: "<http://sbc.exotel.com|sbc.exotel.com>"

in the trunk. • Ensure your outbound trunk numbers and any auth fields match Exotel’s required formats. • LiveKit performs SRV lookups; if Exotel requires clients to use a specific host/port without SRV, they must provide that FQDN or A record. If you want, I can: • Draft a short message for Exotel including the exact log line and a request to check for INVITEs at the provided timestamps. • Review any DNS/trace outputs you paste here and point out the next step. Which do you prefer? Sources: Self-hosted SIP server | LiveKit docs | sip | livekit/livekit_composite | DeepWiki | Deploy to a VM | LiveKit docs | Ports and firewall | LiveKit docs | Configuring firewalls | LiveKit docs

Thanks — I see the error: "call was not authorized by trunk configuration" on an inbound call. What this means • The inbound call to the trunk was rejected because the called number or caller details don’t match the trunk's allowed configuration. Immediate checks and fixes 1. Confirm the called number is listed exactly in the trunk

numbers

array in E.164 format (e.g.,

+917969415087

). 2. Ensure there are no extra characters or formatting differences (spaces, brackets, tel: prefix) between Exotel’s dialed number and the trunk config. 3. If you expect multiple numbers on the trunk, add them all to the trunk

numbers

and save/update the trunk. How to update the trunk quickly • Via CLI/API: update the trunk JSON to include the exact E.164 numbers, for example:

{
  "sipTrunkId": "ST_uLUcbqZ8HXS8",
  "name": "Exotel Inbound Trunk",
  "numbers": [
    "+917969415087",
    "+918766749695"
  ]
}

• After updating, retry the inbound call and note the timestamp. If the call still fails • Paste the exact trunk JSON you currently have (copy/paste) and one failed call timestamp (UTC). I’ll check for mismatches and draft a one-line request to Exotel to confirm what number they’re presenting as the destination.

Thanks — the logs show inbound INVITEs coming from a private IP (10.60.5.81), so LiveKit is rejecting them as "not authorized by trunk configuration." What to do next 1. Ask Exotel for the public static outbound IP(s) they use for SIP signaling (TCP/UDP 5060 or TLS 5061). Do NOT accept private IPs (10.x/172.16.x/192.168.x). 2. Update your inbound trunk

host

to Exotel’s public IP(s) (or have them confirm a public FQDN) and ensure the trunk

numbers

array includes the exact E.164 destination (e.g., "+917969415087"). 3. Confirm transport/port with Exotel — your logs show TCP on 5060; ensure Exotel will send INVITEs via TCP 5060 (or instruct if TLS 5061). 4. Retry a call and capture a timestamp + agent log snippet (run

lk agent logs --log-type=deploy --id=<agent-id>

) for the attempt. Quick message you can send to Exotel (paste as-is) Hi — our LiveKit inbound trunk is rejecting INVITEs because they appear from a private IP (10.60.5.81). Please provide the public static IP address(es) you use for outbound SIP signaling to external trunks and confirm the transport/port (TCP/UDP 5060 or TLS 5061). Also confirm which caller/destination numbers you present to upstream trunks. Example log line: fromUri: {host: "10.60.5.81", transport: "SIP_TRANSPORT_TCP"} Timestamp: [paste UTC timestamp of failed attempt] What I can do for you • Draft a shorter/longer message to Exotel. • Validate your updated trunk JSON if you paste it here. • Analyze agent log snippets/timestamps after you retry. Which would you like me to do now? Sources: SIP Lifecycle Management Agent | LiveKit docs | Accepting calls overview | LiveKit docs | sip | livekit/livekit_composite | DeepWiki