Thanks — I hear your frustration. You’re describing two related problems: Twilio calls ring once then hang up (repeats a few times then stops), and Vobiz calls disconnect immediately before the first ring. I can help — to diagnose this we’ll need a few targeted details and logs. Please provide the following so I can pinpoint the cause: 1. Container logs (most important) •

docker logs livekit-server

,

docker logs livekit-sip

, and

docker logs redis

captured during an outbound call attempt. Look for SIP messages (INVITE, 180/183, 200, ACK, BYE) or any errors. 1. SIP outbound trunk configuration for each provider (Twilio and Vobiz) • The exact settings you used when creating the trunk (SIP URI, auth method: IP-whitelist vs username/password, transport: `udp`/`tcp`/`tls`, port). • Any credential or example payload (you can redact secrets) such as:

{
  "sip_uri": "sip:example.sip.provider",
  "transport": "tcp",
  "auth_type": "ip",
  "username": "...",
  "password": "..."
}

1. How you are initiating the outbound call • Are you using the Agents API (e.g.,

CreateSIPParticipantRequest

) or another method? If using the API/SDK, paste the request payload (redact secrets). Note if you use

wait_until_answered

or similar flags. 1. Network / NAT details • Is this deployment behind NAT or a firewall? Are SIP (5060/5061) and RTP media ports forwarded (commonly 10000–20000)? • Did you set

public_advertise_address

or equivalent in

livekit-sip

to your public IP/hostname? 1. Transport and media settings • What transport are you using to reach Twilio/Vobiz (

udp

,

tcp

, or

tls

)? Twilio often prefers TCP/TLS for trunks. • Are you sending media over UDP and not using TURN? Without TURN, NAT or blocked UDP can cause one-way audio or call teardown. 1. Any SIP traces or packet capture (optional but very helpful) • If possible capture SIP traffic during a failed call: tcpdump example:

tcpdump -i any -s 0 port 5060 -w sip_capture.pcap

Share the pcap (or relevant SIP dialog lines) showing INVITE → responses → BYE. Quick checks you can run now • Switch the trunk transport to TCP/TLS (if currently UDP) and test again — Twilio often requires/works better with TCP/TLS. • Ensure the outbound trunk allows calls from your public IP (Twilio requires IP ACLs for IP-auth trunks). • Confirm caller ID settings on Twilio — Twilio may reject or drop calls with unverified caller IDs. • Verify

public_advertise_address

and RTP port forwarding so remote providers can reach your media ports. • Try one test call while capturing logs from

livekit-sip

and

livekit-server

and share them. Why I’m asking these things • A premature BYE usually means a signaling or media validation failure (transport mismatch, NAT/ICE/media not reachable, or provider rejecting the call). The difference between Twilio (rings then quits) and Vobiz (hangs immediately) points to provider-specific transport/auth requirements or media negotiation failing before ring completes. If you share the logs and the trunk configs (redact secrets), I’ll read the SIP flow and tell you exactly which message is causing the teardown and the practical fix. Sources: Preserve caller ID during SIP transfers with Twilio | LiveKit | Firewall Tips for LiveKit Connectivity | LiveKit | Agents telephony integration | LiveKit Documentation | Support data sovereignty in India | LiveKit