For years, Odoo’s built-in video calling felt like it was holding something back. The interface had recording controls. The buttons were there, visible to any user who joined a call through Discuss. But pressing them didn’t actually produce a recording. The front-end signaled intent; the back-end had nowhere to send the media. That gap has now closed. Odoo’s Selective Forwarding Unit — the server component that routes audio and video streams between call participants — ships a complete recording pipeline that captures media server-side, encrypts it locally, compiles it into deliverable files, and uploads the finished product back to Odoo through authenticated callbacks.
From Placeholder Buttons to a Real Recording Stack
The disconnect between the recording UI and actual capture capability was one of those quietly frustrating gaps in Odoo’s communication stack. Users would click “Record,” see visual feedback suggesting something was happening, and then find nothing saved when the call ended. It wasn’t a bug in the traditional sense — the signaling layer acknowledged the recording flag — but the SFU server had no mechanism to intercept media streams, write them to disk, or process them into a usable format.
The new implementation adds four interlocking components to the SFU: a recorder that taps into the forwarded media streams and writes raw track data, a schedulerthat manages recording lifecycle events and serializes start/stop operations so concurrent requests don’t corrupt state, a compiler that takes the raw captured streams and assembles them into standard media files, and an upload handler that delivers the finished recording to Odoo through authenticated HTTP callbacks. Each component operates independently but feeds the next, forming a pipeline that runs entirely on the SFU server without requiring any browser-side capture.
Encryption at Rest, Authentication in Transit
Call recordings are sensitive by nature, and Odoo’s implementation treats them accordingly. Recording metadata is encrypted locally on the SFU server, meaning that even if someone gains access to the server’s filesystem during a call, the metadata describing who initiated the recording, which participants were present, and when segments started and stopped is not readable without the appropriate keys.
The upload mechanism relies on authenticated callbacks rather than a simple file push. When a recording completes compilation, the SFU doesn’t just POST the file to an endpoint — it goes through Odoo’s authentication layer with JWT tokens that have been tightened specifically for this release. Token handling now enforces Base64url encoding, requires finite future expiration times (no more indefinite tokens), and uses typed claims that the receiving Odoo instance validates before accepting the upload. The identity of the user who initiated the recording travels through the entire pipeline via metadata, creating an audit trail from the moment someone presses “Record” to the moment the file lands in storage.
Graceful Shutdown Changes the Reliability Equation
One of the less obvious but more important changes is how the SFU handles shutdown during active recordings. Previously, stopping the media service or the channel service was a fire-and-forget operation. If a recording was in progress when the server shut down — for a deployment, a restart, or a crash recovery — the in-flight media was simply lost.
Channel and media service shutdown are now awaitable operations. When the SFU receives a shutdown signal, it waits for recording finalization to complete before releasing transports and cleaning up temporary files. This means a server restart during an active call no longer silently discards whatever was captured up to that point. The recording pipeline gets a chance to compile and upload what it has. It’s the kind of change that doesn’t matter until it does — and when it does, it’s the difference between having the recording and not.
WebSocket Cleanup and Connection Hygiene
Alongside the recording feature, the SFU’s connection tracking has been overhauled. Previously, WebSocket connections that failed during the handshake or disconnected before completing authentication could linger in the server’s internal registries — ghost entries that consumed memory and could interfere with participant counts. The cleanup logic now ensures that sockets that fail or disconnect early are immediately purged from both the pending and authenticated connection pools.
This matters for recording because participant tracking directly affects what gets captured. A phantom socket in the registry could cause the recorder to allocate resources for a stream that will never arrive, or worse, prevent it from properly detecting when all real participants have left and the recording should finalize. Clean connection state is a prerequisite for reliable recording, and the SFU now maintains it properly.
A Deliberate Approach to Failure
Not every design choice in the recording pipeline is about adding capability. One of the more interesting decisions is how the system handles failures: it doesn’t retry. If the compilation step produces a corrupted file, or if the upload callback fails, the recording is discarded. There’s no retry queue, no dead-letter mechanism, no background job that will attempt redelivery an hour later.
This is a deliberate trade-off. Retry logic for large media files introduces complexity that can cascade — partial uploads that consume storage, duplicate deliveries that confuse users, zombie processes that hold file handles open indefinitely. By treating failed recordings as unrecoverable, Odoo keeps the SFU server stateless between calls. The recording either makes it through the full pipeline or it doesn’t exist. For a system that needs to handle potentially dozens of concurrent calls, that simplicity is worth the occasional lost recording from a network hiccup.
What This Means for Odoo as a Communication Platform
The recording capability is more than a feature checkbox. It repositions Odoo’s built-in calling from “good enough for a quick internal chat” to a tool that can serve compliance-sensitive industries. Legal teams that need to retain client call records, sales organizations that review call recordings for coaching, and support teams that archive escalation calls all had to route those conversations through external tools — Zoom, Teams, Google Meet — even though they were already inside Odoo for everything else.
With server-side recording, encrypted metadata, authenticated uploads, and the recordings landing directly in Odoo’s storage, those external dependencies become optional rather than mandatory. The architecture is also structured for future extension — the compiler stage is where transcription would plug in, and the upload callback pattern supports delivering recordings to destinations beyond Odoo’s built-in file storage. For now, though, the headline is simpler: the record button in Odoo Discuss finally does what it always looked like it should.