Issue with a LiveKit-provided phone number

Getting Started
1

:waving_hand: Hey all — running into an issue with a LiveKit-provided phone number that I’d appreciate a second set of eyes on.

Symptom: Inbound calls to my provisioned number ring indefinitely on the caller’s side and never produce any activity in LiveKit — no session is created, no SIP event is logged, and no job is dispatched to my agent. The number shows ACTIVE in the dashboard.

Setup (all verified):

  • Phone number is ACTIVE and linked to an Individual dispatch rule (room prefix: call-).

  • Dispatch rule’s agent target matches my agent name exactly (inbound-agent).

  • A worker is registered and healthy under that exact name (tried both cloud-deployed and self-hosted local worker — same result).

  • Just confirmed the agent itself works end-to-end via the Agent Console over WebRTC (full STT → LLM → TTS conversation). Only the inbound PSTN → SIP path is failing.

What I’ve already tried:

  • Confirmed dispatch rule’s agent target matches the registered worker name exactly.

  • Deleted the old cloud deployment and re-registered the agent as a clean self-hosted worker.

  • Restarted the worker cleanly, watched the registration log — registers fine, just never receives a job request.

  • Multiple test calls from different originating numbers — identical behavior every time (rings forever, no session record, no SIP event).

This makes me suspect the upstream carrier/DID provisioning for this number didn’t complete properly, even though the dashboard shows it ACTIVE.

Questions:

  1. Has anyone seen a LiveKit-provided number show ACTIVE but actually be unprovisioned upstream?

  2. Is there a way to view SIP ingress logs at the carrier level to confirm whether calls are even reaching LiveKit’s edge?

  3. Is there a standard way to escalate a “fix or replace this DID” request?

Any guidance appreciated :folded_hands:

2

@Adam_Hanneman, Your diagnosis is right. Zero SIP events on LiveKit’s side means the calls aren’t reaching the edge at all; if they were, you’d see an entry even on a dispatch miss (typically a 404). With ACTIVE in the dashboard but no edge activity, it’s almost certainly carrier-side provisioning: either the upstream DID route never finished propagating, or the number is bound to a different project’s SIP endpoint.

Answers to your three:

  • Yes, this happens. ACTIVE in the dashboard ≠ carrier route is live; the two states can desync, particularly right after provisioning.
  • Not from the customer side. Edge / ingress logs are Cloud-internal. The forum and OSS surface can’t see them.
  • Cloud support is the path. @CWilson, I believe you can better assist here; your data (number ACTIVE, dispatch correct, agent verified via Console) is already a complete repro for them to check carrier-side routing.

One sanity check before you escalate: confirm the SIP URI in Project Settings (<subdomain>.sip.livekit.cloud, where subdomain = your project ID without the p_ prefix) belongs to the project that owns the number. Cross-project misbinding has caught BYOT setups before.

3

This problem is almost always one of two things:

  1. You did not set the same agent name in your agent session that is defined in the dispatch rule “inbound-agent”
  2. Your agent is crashing for some reason. In this case check your agent logs to see what might be happening.

One thing that I see with your specific setup, and that is very uncommon, is that you have set inboundNumbers condition in your dispatch rule. I am 99.9% sure this is the issue in your case, since it is the same number defined for the trunk. The number in the dispatch rule is the caller’s number, not the agent’s.

See: Dispatch rule | LiveKit Documentation