TransferSIPParticipant returns 412 before inbound SIP call becomes active

Telephony
,
1

We need to redirect an inbound SIP caller immediately after dispatch, before starting our full AgentSession. ctx.waitForParticipant() returns successfully, but transferSipParticipant() then returns Twirp 412:

failed_precondition: can't transfer non established call

We’re using @livekit/agents 1.6.4, @livekit/rtc-node 0.13.33, and livekit-server-sdk 2.15.3.

From the LiveKit SIP source, it appears inbound calls remain ringing until the SIP participant subscribes to a remote audio track. Only afterward does LiveKit accept the SIP call, set sip.callStatus=active, and allow REFER.

For an immediate startup redirect where we don’t otherwise need an AgentSession, is the supported pattern to publish a temporary audio track, wait for sip.callStatus=active, and then call TransferSIPParticipant? Or is there a supported pre-answer redirect mechanism that avoids starting an audio publisher/full agent session?

2

Hi Dan, yes, we don’t support transferring a call before it is established.

Looking at the code, your workaround to accept the call, publish a temporary audio track, wait for sip.callStatus==active and only then calling TransferSIPParticipant would be the most sensible approach.

I see this is also an internal thread, so I’ll ping internally about this.

3

Thanks I tested this locally and the workaround works for us.

Longer term, a first-class way to accept or establish an inbound SIP call for an immediate transfer would be really useful. Our use case is repeat callers: if someone calls our AI agent and we see that the same caller was transferred to a human in the last 30 minutes, we want to send them straight back to that destination instead of making them start over with the AI. Usually the previous transfer was dropped, or they’re calling back to confirm something with the representative

Publishing a temporary silent track and waiting for sip.callStatus=active works, but it feels like extra lifecycle plumbing for a call the agent never needs to handle. An explicit accept/establish API, or support for transferring during setup, would make this flow much cleaner

4

Thanks Dan and understood. I see the same request to Rick Cheng internally so I’ll let him answer the feature request formally there, since he’s in charge of your enterprise account.