Hi, we’re on LiveKit Cloud, project ID: p_okztf07p5pn, using livekit-server-sdk 2.16.0.
Outbound works perfectly — dialWhatsAppCall + connectWhatsAppCall (forwarding the
SDP answer from Meta’s webhook) gives stable two-way audio.
Inbound never connects: on Meta’s connect webhook we call acceptWhatsAppCall with
the SDP offer within ~2s. Without waitUntilAnswered the RPC returns OK and a wa-…
participant joins the room with an audio track — but the caller’s phone keeps
ringing, and Meta’s terminate later shows the call was never answered (no
start_time/duration). With waitUntilAnswered: true it fails after ~30s with
“request timed out”. Manual accept and agent-dispatch accept both fail identically.
We verified: the webhook SDP offer is well-formed (byte-level check), tested
whatsappCloudApiVersion 23.0 and 25.0 (app webhooks are v25.0), each connect is
processed exactly once. The same WABA/number works fine for outbound.
Example failed call: 2026-07-07 ~15:44 UTC, callId
wacid.IhggMDA5NjNGMTczOUVEQTA1NEYwQ0VGMDAyREQ0RjVEMUEcGAsxNTU1ODc0MDg0OBUCABUUAA==
Could you check the connector logs for our project? Is inbound accept fully
That time aligns with call RM_TGgkTuzezBWx.
I see the call coming into the server logs, and the job being assigned to an agent, but the agent never joins.
So, it looks to me like something is preventing your agent from joining, and answering the call.
I don’t see any agents deployed to your project right now (here) - it might be worth deploying our starter agent to LiveKit cloud, named to correspond with the name given in your acceptWhatsAppCall, and trying again.
Thanks Darryn — solved! Your pointer was exactly right. Two issues on our
side: (1) our locally-running agent worker kept crashing on Windows — the
SDK’s memory monitor polls pidusage, which fails on this machine (“Starting
the CLR failed”) and the unhandled rejection took the whole worker down, so
the agent was always dead or cold-starting when calls arrived; we guard that
now and the worker stays warm. (2) waitUntilAnswered on acceptWhatsAppCall
deadlocked our manual-answer path (the frontend needs the token before it
can join) — removed. Inbound calls now connect and the AI agent answers and
talks. You might want to look at the pidusage failure path in the JS SDK on
Windows — an unhandled rejection there kills the worker. Thanks again!
I would like to. How can I reproduce this? You say ‘locally running agent’, so is it just a case of running GitHub - livekit-examples/agent-starter-node: A complete voice AI starter app for LiveKit Agents with Node.js · GitHub on my Windows 11 machine?
Inbound WhatsApp calls intermittently never bridge (accept OK, agent joined, no start_time) — reliable repro: immediate redial fails, ~2-min gap succeeds
Hi, following up on this thread (same project as earlier).
Inbound calling works, but intermittently — in streaks — an accepted call never bridges:
- acceptWhatsAppCall returns success within 3–5s of the connect webhook
- Our agent (unique agent name, verified single worker) joins the room a few seconds later
- Greeting audio is generated and forwarded; the caller’s audio track is even subscribed
- Yet the caller keeps hearing ringing, and Meta’s terminate webhook arrives with no start_time / no duration — the call never connected
Reliable reproduction we found: redialing immediately after a previous call ends → fails to bridge. Redialing after a ~2-minute gap → connects consistently. This suggests per-call/per-number teardown or cleanup state on the connector side.
From today, 2026-07-11 (UTC), same caller number:
Successful: 07:48 (75s), 07:49 (42s), 07:51 (181s), 09:23 (249s), 10:45 (199s)
Failed (accepted <5s, agent joined, never bridged — note the last four are rapid redials right after the 199s success ended):
07:39 wacid.IhggMDA2MjQ0Njg1MEZCMjk5QkMxOTA2NTA2Q0U4MjRDRUUcGAsxNTU1ODc0MDg0OBUCABUUAA==
07:46 wacid.IhggMDBDOEE4MERDM0RDQkY3MjgyOTQxRTczNEI1MEQ5MTccGAsxNTU1ODc0MDg0OBUCABUUAA==
08:07 wacid.IhggMDBDQzQ1NDc2MjU0OEU5NUNFNTY3MDM5OEJDMjUxRjkcGAsxNTU1ODc0MDg0OBUCABUUAA==
09:55 wacid.IhggMDA4NEMzQTE4QjFENzk1RjkzQzY1NEZBRkY5RDc1QkUcGAsxNTU1ODc0MDg0OBUCABUUAA==
09:56 wacid.IhggMDBCOENDQzVGQkMxMkYwOEIxNzAwNEQ2OTUyM0JEMkIcGAsxNTU1ODc0MDg0OBUCABUUAA==
09:57 wacid.IhggMDA4QzhGQTY1RDZERkJBODQzM0I2ODFENzQ0Q0UxQ0UcGAsxNTU1ODc0MDg0OBUCABUUAA==
10:57 wacid.IhggMDAxMUIyOEQ3MjBBMENDMTRBN0MyQUEyMDRFQzc5QzkcGAsxNTU1ODc0MDg0OBUCABUUAA==
10:57 wacid.IhggMDBCQTA0ODlFQTNFRjQ4OTk5QkE3REM4MEVBNkYwQkIcGAsxNTU1ODc0MDg0OBUCABUUAA==
10:58 wacid.IhggMDBDRDRFMUYwMzIwOUNDMDZDQjE3RjgzQkRCMTEwRDYcGAsxNTU1ODc0MDg0OBUCABUUAA==
10:58 wacid.IhggMDA3NEE4RkY5MjU0QTY0NzgwNTUxMDFFMENCNkFGMjkcGAsxNTU1ODc0MDg0OBUCABUUAA==
Could you check the connector logs for the failed call IDs — did the accept/SDP handshake to Meta fail, time out, or get throttled? And is there a minimum interval needed between calls from the same number?
Happy to provide more call IDs or run any test you need. Thanks!
I have also faced this issue of;
redialing immediately after a previous call ends → fails to bridge
When I redial immediately after a call ends, I see that meta sends the connect webhook & the call is answered, but the Livekit agent doesn’t join the call. When I wait for 2 minutes and redial, the call is answered & the livekit agent joins the call and talks.
redialing immediately after a previous call ends → fails to bridge
Usually this is caused by the reuse of room names, and the agent not joining the room with the reused name since it corresponds to the same session.
That would explain why the agent does not joint the call ^ but just focusing on the Failed room at 0807 UTC, I believe it is this one:
https://cloud.livekit.io/projects/p_okztf07p5pn/sessions/RM_TmKqGfP9r9ZK/events
But the session events indicate the whatsapp caller joined, as did the agent, and the session proceeded for 25 seconds, so it looks successful?
I would recommend ensuring you have a unique room name for each call, which you can specify in dialWhatsAppCall
Thanks Darryn! Two clarifications:
Room names are already unique per call — we generate wa-in-- / wa-out-- for every call, so no room is ever reused. The failed calls each had distinct rooms (e.g. wa-in-923017074429-1783766708185, …-1783767425693, …-1783767511089).
On the 08:07 session “looking successful”: that’s exactly the confusing part. From the room’s perspective everything ran (agent joined, WhatsApp participant joined, ~25s session) — but the actual caller’s handset kept showing ringing the entire time, and Meta’s terminate webhook arrived with no start_time / no duration, which in Meta’s semantics means the call was never answered at the WhatsApp-client level. So the room was live while the phone never bridged.
Could you check the connector’s Meta-side accept for the failed call IDs — the pre_accept/accept API calls and Meta’s responses? It looks like the accept toward the handset didn’t complete (or completed too late), even though the room session started. The repro is still consistent: immediate redial after a call ends → never bridges; redial after ~2 minutes → connects fine.
The repro is still consistent: immediate redial after a call ends → never bridges; redial after ~2 minutes → connects fine.
Let me try and reproduce this
Title: Inbound WhatsApp calls fail with livekit_room_disconnected — media never connects
Hey everyone 
I’m using LiveKit’s WhatsApp Business Calling connector (Graph mode, SIP
disabled) for inbound calls. The room gets created and my agent joins fine,
but the media path to Meta never establishes — the caller’s phone just keeps
ringing and the call ends as FAILED.
On the connector’s call detail page I see:
- Status: FAILED
- Error: livekit_room_disconnected
- FROM field is empty (—) even though it’s an inbound call
- Direction: inbound, Type: whatsapp
Already checked on my side:
- API key/secret/URL are correct (rooms create, agent dispatch works)
- Both the WhatsApp caller participant and my agent join the room
- Meta calling settings: status ENABLED, SIP DISABLED, webhook_delivery ENABLED
- My accept call to Meta succeeds (I get CONNECTOR_ANSWERED)
- Cloud API version I send on accept: 25.0
Has anyone hit livekit_room_disconnected with an empty FROM on inbound
WhatsApp calls? Is this a version thing, or is the caller SDP/session not
reaching the connector properly? Any pointers appreciated 