Hi LiveKit community,
We’re building an agent-assisted warm-transfer workflow on a fully self-hosted LiveKit deployment, including the LiveKit server, SIP service, and Agents workers.
The documented WarmTransferTask appears to create a separate consultation room for the human recipient and then use the RoomService MoveParticipant API to move that SIP participant into the caller’s room. However, the documentation currently marks MoveParticipant—and ForwardParticipant—as LiveKit Cloud-only.
Could someone clarify the current roadmap and recommended approach?
-
Are there plans to make
MoveParticipantavailable in the open-source/self-hosted LiveKit server? -
What is the recommended way to implement a true warm transfer on self-hosted infrastructure today? In particular, we need to:
-
place the caller on hold;
-
dial a human into a private consultation;
-
let the agent provide context;
-
connect the human and caller if accepted;
-
return to the caller if the transfer is declined or unanswered.
-
-
Is a single-room implementation using participant permissions, track subscriptions, or muting considered a supported alternative, or are there privacy/audio-routing limitations that make this unreliable?
-
Are there other practical approaches, such as using an external SIP/PBX conference bridge or a SIP transfer operation, while retaining the ability to return to the original caller if the human does not accept?
-
Does LiveKit offer an enterprise or commercial on-premises license that includes
MoveParticipant,ForwardParticipant, or other functionality currently limited to LiveKit Cloud? We have deployment requirements that prevent us from using LiveKit Cloud for the media server.
Any architecture examples or guidance from teams running warm transfers on self-hosted LiveKit would be greatly appreciated.