does SIP REFER closes the room?

Thanks for reaching out, luisa. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

My recording stopped working on SIP REFER it still works on SIP INVITE

Thanks — that’s helpful detail. You said recording stops when a SIP REFER happens but continues with SIP INVITE. I’ll explain the most likely causes and give focused troubleshooting steps so we can narrow this down. Short answer • SIP REFER itself does not close the LiveKit room, but the transfer flow often changes or ends the original SIP session. If your transfer flow removes participants or deletes the room (or otherwise ends the media session), the egress (recording) will stop. To keep recording, the room and the egress participant must remain active through the transfer. Quick checklist to diagnose and fix 1. Confirm whether your transfer is “cold” (forward/replace) or “attended” (consultative): ◦ Cold transfers often terminate the original session and can remove media that egress is recording. ◦ Attended/bridge transfers can often preserve the original room/media for longer. 1. Check for explicit room deletion or participant removal in your transfer code: ◦ Search your transfer handling for calls to

delete_room

or logic that disconnects participants when REFER completes. If present, that will stop recording immediately. ◦ If you find such logic, modify it so the room stays active while you want recording to continue. 1. Inspect egress/egress_ended webhooks and logs: ◦ Look for an

egress_ended

webhook or any egress error events around the time of the REFER. That will show whether egress ended due to a deliberate stop, a failure, or loss of media. ◦ Check for

backupStorageUsed

or other failure indicators in those events, which point to egress issues. 1. Verify SIP dispatch rule / auto-egress configuration: ◦ Ensure your SIP dispatch rule’s

room_config.egress

is set to record the target session and that the rule still applies after the REFER transfer. ◦ If the REFER results in a new SIP endpoint that isn’t covered by the same dispatch rule, auto-egress might not restart. 1. Reproduce with logs and minimal flow: ◦ Reproduce the transfer with verbose SIP logs + LiveKit server logs. Confirm whether the SIP INVITE flow keeps the same media session and whether REFER results in session re-INVITE/termination. ◦ If you can reproduce in a test room, you can more safely try changes (e.g., avoid deleting the room). What I can help next • If you want, tell me: ◦ Whether your transfer is cold or attended. ◦ Whether you see any

egress_ended

events or room-deleted events around the transfer time. ◦ If your code explicitly calls

delete_room

or disconnects participants on REFER. • I can then give a targeted change to keep egress running (for example: preserve the room during transfer, adjust dispatch rules, or modify the transfer flow), and show example API/webhook checks to confirm the fix. Which of those follow-ups can you provide? Sources: Company directory phone assistant | LiveKit Documentation | examples/frontdesk | livekit/livekit_composite | DeepWiki | Agents telephony integration | LiveKit Documentation | SIP Lifecycle Management Agent | LiveKit Documentation | Backup Egress Recordings