SIP inbound returns 503 but no record in Calls dashboard

Project: alertivo (id: p_23wunvd1nk2), region Germany 2.

Inbound SIP calls from Twilio Elastic SIP Trunk fail with SIP 503, but nothing appears in the Calls dashboard (Telephony → Calls, past 24h shows “No results”). I’m at my wit’s end on
diagnosis.

Setup:

  • Twilio origination URL: sip:23wunvd1nk2.sip.livekit.cloud;transport=tcp
  • Inbound trunk ST_tjNxEUu9gGtf, numbers +420910923523,420910923523, no auth, encryption DISABLE
  • Dispatch rule SDR_g3rVynwCybMM, Individual (Caller), roomPrefix: “call-”, references the trunk, room_config.agents: [{agent_name: “alertivo-support”}]
  • Agent worker registered as agent_name: “alertivo-support” (livekit-agents 1.5.4, AgentServer + @server.rtc_session(agent_name=…) pattern)
  • Twilio call SID example: CA097cd1e8a4f4a2f391f7534c7a033f62, returns: 503 service error with sip:+420910923523@23wunvd1nk2.sip.livekit.cloud;transport=tcp

What works:

  • Manual dispatch via lk dispatch create --agent-name alertivo-support --room … works end-to-end — agent receives job, connects Deepgram STT, etc.
  • SIP OPTIONS over TCP to 23wunvd1nk2.sip.livekit.cloud:5060 returns SIP/2.0 200 OK
  • SIP URI on Trunks page shows sip:23wunvd1nk2.sip.livekit.cloud (no custom port)
  • UDP 5060 times out — confirming TCP-only behavior

What doesn’t:

  • TCP INVITE returns 503 every time (5x retries visible in Twilio debugger)
  • Calls dashboard shows nothing for these attempts — so the INVITE never becomes a registered “call” in LiveKit

Any idea why the SIP edge returns 503 without registering the call? Is there a known issue with room_config.agents auto-dispatch for SIP inbound, or a specific flag I’m missing?

Can you try removing 420910923523 from the trunk, so you are just left with the +420910923523, and tell me if that solves your issue. We used to have an issue where these “duplicates” would cause an issue, but I thought that was resolved.

That fixed it, thank you! Removing “420910923523” and leaving only “+420910923523” on the inbound
trunk did the trick. Inbound PSTN calls from Twilio now route to the agent as expected. Much appreciated.

Thank you for reporting back, I’ll follow-up internally in case this (de-duplication) is a regression.

Glad it’s now working.