# Cloud Agents: SIP inbound returns 503 before Call object created — public-side debug exhausted **URL:** \ **Category:** Cloud Dashboard\ **Tags:** agent-sdk-python, agent-deployment, livekit-phone-numbers, sip-twilio, sip-trunking\ **Created:** [May 9, 2026, 4:43am UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065 "2026-05-09T04:43:47Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Nick\_O\_Connor](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/nick_o_connor/32/1289_2.png) [@Nick\_O\_Connor](https://community.livekit.io/u/Nick_O_Connor)\ **Post date:** [May 9, 2026, 4:43am UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/1 "2026-05-09T04:43:47Z")
Hi LiveKit Cloud Support, object is created. Public-side debugging in the community forum ([https://community.livekit.io/](https://community.livekit.io/)) ruled out every documented configuration cause; the issue is now confirmed to require edge log visibility. **All the IDs/data your team will need:** lk CLI: 2.16.3 Secure=true **Recent failed call SIDs (Twilio side, all 100-\>503 within ms, all trunking-originating direction, all duration 0):** CAef2096a9d602ccd5d9403f5436d5d9c7 2026-05-09 02:31:30 UTC **SIP wire trace (reproducible via direct openssl s\_client probe):** ``` From: ;tag=... CSeq: 1 INVITE ``` ← SIP/2.0 100 Processing ← SIP/2.0 503 Try again later **What works (rules out the obvious):** - ✅ DNS resolves: 6zow2x1cz42.sip.livekit.cloud → 161.115.181.19/35 the job, runs entrypoint, function tools fire normally **Trunk JSON:** { ``` "name": "sweet-rebas-twilio-inbound", "allowedAddresses": \[ \], "maxCallDuration": "1800s" ``` } (auth\_username, auth\_password, media\_encryption all omitted — cleared per docs that inbound = IP whitelist only.) **Dispatch rule JSON:** { ``` "roomConfig": { "departureTimeout": 15, "maxParticipants": 4, } ``` } **Telephony → Calls dashboard shows No results for past 24h** despite multiple SIP attempts above — so the 503 happens before the call is logged in project history. **Question:** could someone with internal SIP edge log access tell me what the rejection reason is for these specific INVITEs? Once I know what the edge is checking that fails, I can fix it. Public-side I’ve exhausted the configuration vectors. Forum thread for context: Thanks for any help — ---
**Author:** ![Muhammad\_Usman\_Bashir](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/muhammad_usman_bashir/32/1149_2.png) [@Muhammad\_Usman\_Bashir](https://community.livekit.io/u/Muhammad_Usman_Bashir)\ **Post date:** [May 9, 2026, 7:54pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/2 "2026-05-09T19:54:04Z")
The `openssl s_client` probe getting the same `100 >> 503` rules out trunk config, at the rejection point, the edge isn’t consulting your `allowedAddresses` or numbers. `503` (vs the more typical `404 / AuthNoTrunkFound` for a trunk-match miss) suggests a Cloud-side dependency is unreachable, not a routing miss. Worth one quick sanity-check before escalating: [LiveKit Cloud: Inbound BYOT trunk returns 404 'No trunk found' despite correct configuration · Issue #592 · livekit/sip · GitHub](https://github.com/livekit/sip/issues/592) (closed, same Cloud-BYOT pattern). Root cause there was the project’s actual SIP URI didn’t match the `*.sip.livekit.cloud` subdomain the user thought was theirs, turned out to belong to a different project on the same account. Confirm `6zow2x1cz42.sip.livekit.cloud` is your project’s SIP endpoint in the Cloud dashboard, not copied from a different project’s outbound trunk page. @CWilson can you please assist here. His data is already complete enough for support to act on. ---
**Author:** ![Nick\_O\_Connor](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/nick_o_connor/32/1289_2.png) [@Nick\_O\_Connor](https://community.livekit.io/u/Nick_O_Connor)\ **Post date:** [May 9, 2026, 11:42pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/3 "2026-05-09T23:42:12Z")
Thanks Muhammad! Confirmed — the SIP URI sip:6zow2x1cz42.sip.livekit.cloud is exactly what’s shown on my project’s settings page (Settings → Project → SIP URI field) and verified via lk project list against project ID p\_6zow2x1cz42. So the URI is correctly tied to my project. Could you point me to issue #592? I’ll dig into it for the cloud-side dependency angle. Also worth noting: an identical pattern is reported in [Twilio SIP INVITEs to LiveKit project p\_3lrmo3qmlaz never logged in Telephony](https://community.livekit.io/t/twilio-sip-invites-to-livekit-project-p-3lrmo3qmlaz-never-logged-in-telephony/1011) — same Twilio + Cloud Agents + 24-byte empty PCAP + zero Telephony dashboard logs symptom — which CWilson responded to but no public resolution was posted. Would be great to get the fix for both threads at once ---
**Author:** ![CWilson](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/cwilson/32/135_2.png) [@CWilson](https://community.livekit.io/u/CWilson)\ **Post date:** [May 11, 2026, 2:22pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/4 "2026-05-11T14:22:03Z")
@Nick_O_Connor You have a configuration error in your trunk. You need to define your turn like this: `+12344568900` Do not define your trunk like this: - `+12344568900` - `12344568900` - `2344568900` Doing the second will cause errors. Also, don’t use a space between the “+1” and the number like this `+1 234567890`. I see you have two inbound trunks, and both have exactly the same problem. I’ve asked the team to be more lenient in that case. ---
**Author:** ![Nick\_O\_Connor](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/nick_o_connor/32/1289_2.png) [@Nick\_O\_Connor](https://community.livekit.io/u/Nick_O_Connor)\ **Post date:** [May 12, 2026, 8:41pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/5 "2026-05-12T20:41:10Z")
thanks for that. Unfortunately i still have issues. > **[Slack | AI Work Platform & Productivity Tools](https://livekit-users.slack.com/?redir=%2Farchives%2FC088ZNU7QQ5%2Fp1778602287269369%3Fname%3DC088ZNU7QQ5%26perma%3D1778602287269369)** > > Boost productivity and save time with Slack‌ — ‌the AI work platform for managing projects, automating workflows, and connecting teams securely. Start working smarter today. ---
**Author:** ![Nick\_O\_Connor](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/nick_o_connor/32/1289_2.png) [@Nick\_O\_Connor](https://community.livekit.io/u/Nick_O_Connor)\ **Post date:** [May 12, 2026, 11:05pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/6 "2026-05-12T23:05:10Z")
any help finding the cause and solutions would be very helpful. ---
**Author:** ![CWilson](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/cwilson/32/135_2.png) [@CWilson](https://community.livekit.io/u/CWilson)\ **Post date:** [May 13, 2026, 3:05pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/7 "2026-05-13T15:05:03Z")
> [@Nick\_O\_Connor](#): > > p\_6zow2x1cz42 I just checked the trunks for that account again and it is still improperly configured. Why do you define the number multiple times with just different formats? Do not define your trunk like this: - `+12344568900` - `+1 2344568900` - `12344568900` - `2344568900` Just use the ``+1NNNNNNNN`` format not all those variations. See my message above: > [@Cloud Agents: SIP inbound returns 503 before Call object created — public-side debug exhausted](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/4): > > @Nick_O_Connor You have a configuration error in your trunk. You need to define your turn like this: +12344568900 Do not define your trunk like this: +12344568900 12344568900 2344568900 Doing the second will cause errors. Also, don’t use a space between the “+1” and the number like this +1 234567890. I see you have two inbound trunks, and both have exactly the same problem. I’ve asked the team to be more lenient in that case. ---
**Author:** ![Muhammad\_Usman\_Bashir](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/muhammad_usman_bashir/32/1149_2.png) [@Muhammad\_Usman\_Bashir](https://community.livekit.io/u/Muhammad_Usman_Bashir)\ **Post date:** [May 13, 2026, 6:08pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/8 "2026-05-13T18:08:04Z")
Cc: @Nick_O_Connor, CWilson’s #4 and #7 are the actual answer. Your cross-carrier evidence doesn’t disprove a trunk config issue; it confirms it. Both trunks (`ST_zMLJfuZoMHmE` Twilio, `ST_sZ2wnQcAqe8a` Telnyx) have the same malformed numbers list per @CWilson’s check, so both fail `trunk-match` identically at the edge. That’s the “universal” pattern, not a LiveKit-wide regression. > Why manual lk dispatch create keeps landing: it goes through the agent-dispatch service, not the SIP edge’s trunk-match. The cron landing says nothing about whether inbound SIP matches your trunks; different flows, different validation. Concrete fix: - List current trunk numbers (lk CLI or dashboard). - For each trunk, keep exactly one entry per number in `+1NNNNNNNN` format. Drop every variant (`12344568900`, `2344568900`, anything with spaces). - Re-test from your openssl `s_client` probe; should flip from `503` to `200` OK. On the `@0.0.0.0` host in the Twilio `Call-ID:` standard Twilio quirk when the signaling box doesn’t have a public-IP context for `Call-ID` generation. Not diagnostic. @Nick_O_Connor if you need huddle, we can do that for sure to give you more clarity. But I think I have explained the solution and second what @CWilson has proposed. ---
**Author:** ![Nick\_O\_Connor](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/nick_o_connor/32/1289_2.png) [@Nick\_O\_Connor](https://community.livekit.io/u/Nick_O_Connor)\ **Post date:** [May 13, 2026, 6:17pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/9 "2026-05-13T18:17:40Z")
Thanks @Muhammad_Usman_Bashir + @CWilson — you’re right, and that exact fix was applied to both trunks this morning at ~10:23 PT. Confirming current state via `lk sip inbound list`: • Telnyx ST\_sZ2wnQcAqe8a — `numbers: [“+18312309370”]` (single canonical) • Twilio ST\_zMLJfuZoMHmE — `numbers: [“+18313152253”]` (single canonical) The fix has had the predicted effect on Telnyx — it now works end-to-end. Confirmed by phone test: "Hey Nick, welcome back!" plays correctly with the agent’s caller-recognition firing. So the trunk-match diagnosis was right and the fix resolved it on that path. Thank you. Twilio’s behavior changed too, but to a different failure mode. Before the fix: SIP 500 / 503 immediate reject. After the fix: • SIP 200 OK comes back fast (Twilio CDR Post-Dial Delay = 0.034s) • Media bridge IPs negotiated (LiveKit 161.115.178.150 ↔ Twilio 168.86.139.116) • Codec PCMU agreed • Twilio CDR: Status Completed, billed $0.0034, Silence Detected: true • Twilio CDR: Who Hung Up: caller • Agent log: agent connects to room within 21ms of dispatch; SIP participant identity `sip_+14088936886` detected with `sip.callStatus: ‘ringing’`; recognition fires successfully; "personalized context injected for Nick (8 visits)" • Disconnect arrives `CLIENT_INITIATED` at 438-519ms after the agent joins the room, consistently across multiple test calls What Nick (the caller) hears: one ring, then hangup — he’s not pressing end, the call dies on its own. Empty SIP PCAP (24-byte header only) confirms zero RTP packets flowed before the BYE. So: trunk-match is correct on Twilio’s side now; SIP edge accepts the INVITE; agent dispatches successfully; agent enters the room and identifies the SIP participant. But media never starts flowing before something (Twilio? AT&T? LiveKit’s SIP edge?) sends BYE 500ms in. The disconnect timing is suspiciously consistent across calls. Telnyx is structurally identical (same agent code, same dispatch rule shape, same Cloud Agent, single-canonical numbers) and tolerates the cold-start fine. Twilio doesn’t. Given that, are CWilson’s #4 and #7 still pointing at trunk-match? Or is this now a different layer (carrier answer-supervision / early-media policy / SIP edge media-establishment timing)? Happy to send latest Twilio CDR + the agent log lines around the most recent failed call (timestamp 2026-05-13 18:11 PT, Twilio Call SID CAe73cbe09431762aa96e932dc38970680). Huddle would be great if you’re up for it — feels like a sub-500ms timing issue specific to the Twilio path that the trunk fix already cleared elsewhere. ---
**Author:** ![Muhammad\_Usman\_Bashir](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/muhammad_usman_bashir/32/1149_2.png) [@Muhammad\_Usman\_Bashir](https://community.livekit.io/u/Muhammad_Usman_Bashir)\ **Post date:** [May 13, 2026, 8:31pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/10 "2026-05-13T20:31:02Z")
The trunk-match fix landing cleanly on Telnyx vindicates @CWilson’s `#4` and `#7` on that path; that one’s closed. Twilio’s new failure mode is a different layer, you’re right. What you’re seeing is signaling success + media non-establishment: - `SIP 200 OK` round-trip clean - Agent joins room, fires `caller-recognition` - BYE arrives `438-519ms` post-join, zero RTP flowed, Twilio CDR Silence Detected: true The `438-519ms` consistency points at `answer-supervision` on the `Twilio + AT&T` leg cutting the call when no audio arrives within a short window after `200 OK`. Telnyx tolerates the cold-start; Twilio (or the upstream AT&T network through it) doesn’t. Who Hung Up: caller in Twilio’s CDR means the originating side dropped, not Nick pressing end; that’s the network supervisor. Concrete test: ```auto class MyAgent(Agent): async def on_enter(self): await self.session.say("Hello, one moment.") # then do caller-recognition + personalized context injection ``` Fire session.say() immediately on `on_enter`, before any recognition or context lookup. If the `BYE moves past 500ms or disappears, answer-supervision was the cause; the recognition step is too slow to start audio in time on the Twilio leg. Huddle is fine. Drop a time on slack and I’ll be there. Cc: @Nick_O_Connor ---
**Author:** ![CWilson](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/cwilson/32/135_2.png) [@CWilson](https://community.livekit.io/u/CWilson)\ **Post date:** [May 13, 2026, 9:34pm UTC](https://community.livekit.io/t/cloud-agents-sip-inbound-returns-503-before-call-object-created-public-side-debug-exhausted/1065/11 "2026-05-13T21:34:52Z")
> [@Nick\_O\_Connor](#): > > Twilio ST\_zMLJfuZoMHmE — `numbers: [“+18313152253”]` (single canonical) I took a look at the PCAP and I see Twillio is sending a BYE at the same time LiveKit sends the 200OK. I am not sure why Twilio is hanging up the call. I see in your turnk that `Media encryption (SRTP)` is disable but Twilio appears to be negotiating a secure channel. I would try either turning that off on the twilio side or set it to enabled or required on your LiveKit trunk. When setting up a new trunk I find it is easier to setup with clear TCP initially and get that working then add encryption once you have the base trunk working. So check your Twilio account and see if you can find a log for why they hangup.