# SIP inbound returns 503 but no record in Calls dashboard

**URL:** <https://community.livekit.io/t/sip-inbound-returns-503-but-no-record-in-calls-dashboard/930>\
**Category:** Getting Started\
**Created:** [April 22, 2026, 1:54pm UTC](https://community.livekit.io/t/sip-inbound-returns-503-but-no-record-in-calls-dashboard/930 "2026-04-22T13:54:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![marketing](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@marketing](https://community.livekit.io/u/marketing)\
**Post date:** [April 22, 2026, 1:54pm UTC](https://community.livekit.io/t/sip-inbound-returns-503-but-no-record-in-calls-dashboard/930/1 "2026-04-22T13:54:06Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\
**Post date:** [April 22, 2026, 2:22pm UTC](https://community.livekit.io/t/sip-inbound-returns-503-but-no-record-in-calls-dashboard/930/2 "2026-04-22T14:22:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![marketing](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@marketing](https://community.livekit.io/u/marketing)\
**Post date:** [April 22, 2026, 5:30pm UTC](https://community.livekit.io/t/sip-inbound-returns-503-but-no-record-in-calls-dashboard/930/3 "2026-04-22T17:30:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\
**Post date:** [April 23, 2026, 8:15am UTC](https://community.livekit.io/t/sip-inbound-returns-503-but-no-record-in-calls-dashboard/930/4 "2026-04-23T08:15:38Z")

</div>

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

Glad it’s now working.