search

livekit / sip

SIP to WebRTC bridge for LiveKit
84 stars 21 forks source link

Call transfer via SIP REFER #91

Open maik-parloa opened 4 months ago

maik-parloa commented 4 months ago

I wasn't able to find any documentation/source code reference that enables me to transfer an ongoing call (e.g., in the case of a human handover).

Is transferring a call supported / what would be the steps to extend the current implementation to support SIP REFER use cases?

justin0mcateer commented 4 months ago

We also need this capability. From reviewing the code, I am quite certain it is not there currently. However, I was wondering what would be the general approach of getting events or RPC commands from the main LiveKit server to the SIP adapter? I was thinking about how we might be able to implement this functionality.

maik-parloa commented 4 months ago

I'd second this question @justin0mcateer. 👍 Is there a way to send RPC commands from the Livekit Agents to the SIP Gateway? We are also happy to dive into an implementation and open a PR with this capability.

dennwc commented 4 months ago

Could you please explain the use case a bit more? Do you want to transfer SIP participant away from LiveKit SIP server? Or you want to switch existing LiveKit SIP participant to a different SIP endpoint?

maik-parloa commented 4 months ago

The goal is to enable call handovers to Human Agents (e.g. for their existing CCaaS solution). So calls would be transferred to a different SIP URI and the original call would be closed (after the Invite + Refer has been accepted by the target SIP).

justin0mcateer commented 4 months ago

This is very similar to our use case.

However, in our case we need the SIP leg on LiveKit to survive the 200 OK SipFrag from the third-party. We would remove the participant from the LiveKit bridge by another action.

dennwc commented 3 months ago

I'll need to think a bit how to better expose the control API for SIP participants. There were a few similar requests about controlling its behavior (e.g. selective subscription to tracks, etc), so we should define a generic API to send commands. We already have a data channel open for the participant, but using it could be racy (there's a delay between participant creation and data channel coming online). So it should run via our psrpc, probably.

ChrisFeldmeier commented 3 days ago

+1 I also need this

ChrisFeldmeier commented 3 days ago

Twilio has such an transfer API, maybe this can also help you. https://www.twilio.com/docs/sip-trunking#calltransfer SCR-20240910-c78