Cloud Agents: SIP inbound returns 503 before Call object created — public-side debug exhausted

Cloud Dashboard
, , , ,
1

Hi LiveKit Cloud Support,

object is created. Public-side debugging in the community forum (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: <sip:probe@example.com>;tag=...                                                                             

                                                                                                                  

CSeq: 1 INVITE

← SIP/2.0 100 Processing

← SIP/2.0 503 Try again later

What works (rules out the obvious):

  • :white_check_mark: 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 —

2

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 (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.

3

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 —

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

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.

5

thanks for that. Unfortunately i still have issues.

6

any help finding the cause and solutions would be very helpful.

7

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:

8

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.

9

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.

10

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:

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

11

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.