Skip to main content
Back to blog

SIPREC call recording on a CPaaS: what it is, and why compliance buyers ask about it

SIPREC is RFC 7866's protocol for recording a SIP session on the network side, with no desk phones and no client software. That makes it the architecture financial-recording and MiFID II buyers ask for. Here is how the recorder-to-api path joins your platform's carrier, and which controls stay tenant-owned on Devotel Orbit.

Orbit Editorial Team

Quick answer: SIPREC is the IETF's Session Recording Protocol (RFC 7866), a standard way to have the elements in the call path fork the media to a dedicated recorder while the call runs. Nothing sits on the user's device and nothing depends on a browser or handset behaving, so the capture happens wherever the conversation happens. Devotel Orbit records SIP / PSTN calls this way on its carrier plane and joins each finished recording back to the owning account's call record through a signed recorder-to-api callback: the combined recorder-carrier path the lawful-intercept community pinned at architecture level twenty years ago (RFC 8068). On Devotel Orbit that architecture is live today, and the compliance posture on top of it (how long recordings live, who can play them, and when recording is allowed to start at all) is tenant-owned configuration, not platform policy.

This post is the recording-side sibling of the STIR/SHAKEN attestation explainer: a protocol explainer written for buyers, mapped to what already ships.

Why the recorder sits in the network

Client-side recording solves the wrong problem at the compliance layer. A desktop app, a browser extension, or a mirrored conference bot records what reaches that endpoint: a path the user can walk away from, a codec negotiation can degrade, and a device can simply not run. Regulated recording programs learned early that capture has to live in the network elements the conversation traverses, which is why the lawful-intercept community catalogued those elements in the architecture RFC as the legal capture points. A SIPREC sender-recorder pair formalizes that: the Session Recording Client (SRC) sits on the carrier or session border element, the Session Recording Server (SRS) receives the forked streams plus a metadata channel describing who is on the session, and the recording exists independent of any participant's device. Two follow-ons matter to a buyer:

  • It works for any SIP conversation: app calls, desk phone calls, PSTN-via-trunk calls, because the fork happens where all of them converge.
  • It produces a clean lawful-intercept story: the capture point is a governed network function, not an uncontrolled endpoint, which is the story a regulated recorder has to tell.

The failure modes reinforce the same design. When a recorder momentarily falls behind or starts a fork late, it retries, since the SIP protocol layer lets it re-offer the recording session. That means the honest correctness posture for anyone consuming its results is idempotent ingestion, never assumption of exactly-once delivery. And the recorder only ever knows the carrier's session identifiers, the SIP Call-ID family, never which account on the platform the call belongs to. Bridging that gap is the unglamorous, load-bearing part of a SIPREC recording production.

How the recording finds your account

On Devotel Orbit, the path from fork to playable artifact runs through three joins:

  1. Capture. The carrier plane forks a recorded SIP session to a recorder over a SIPREC session, which streams the audio and closes a staged file at call end. A SIP header carrying the call's session identifier rides along so the resulting file can be named and attributed later.
  2. Upload. An uploader service ships the finished file to object storage and then calls the platform API back with the session identifier and the file location. That callback is authenticated with an HMAC-signed envelope, so the ingestion endpoint, which cannot carry a user token, still proves the caller is the recorder and not an internet stranger.
  3. Join back to the call record. The API resolves the session identifier to the owning account and the exact call row, and then, in one flow: writes the recording into the unified recordings store, stamps the playable location onto the call record, emits the call.recording.ready webhook, fans the symmetric lifecycle events (recording.started → recording.completed, or recording.failed on a dead pipeline), kicks off the automatic post-call quality check on the artifact, and appends a tamper-evident audit entry. Exactly-once is enforced at join time: a recorder retry that re-posts the same recording collapses onto the row already written and re-emits nothing, so your downstream systems never double-charge or double-ingest.

When the join completes, every interface sees the same artifact regardless of how it was captured: the recording list in the dashboard, the Recordings API, signed-URL playback, and the webhook feed all treat a SIPREC capture the same as an AI-agent or browser-softphone recording. The recording pipeline concept page walks the same path end to end, and the recording lifecycle page explains why recording.completed fires when the artifact is downloadable rather than when the call hangs up.

Where RFC 7866 answers the compliance-buyer pattern

Searches like "CPaaS lawful recording" or "MiFID II call recording platform" are really asking: does the platform record in the network, and can I prove what happened at capture time. RFC 7866 pages rank for that because the protocol is what those regulations presuppose without naming it:

  • Financial-services recording programs (SMCR, Dodd-Frank, jurisdictional broker-dealer rules) replay the same shape: record in the network, retain per program, keep an audit trail that survives questioning. SIPREC is the standard wrapper for all three properties.
  • MiFID II (European Parliament and Council Directive 2014/65/EU Article 16(7)) requires firms to keep records of telephone conversations that relate to client orders or that could constitute an order even if it never concludes. The MiFID II operative question is not "does the platform have a record button"; it is "capture in the network, track consent and purpose per participant, retain for the mandated window, and produce tamper-evidence on demand." A SIPREC pipeline gives the custody story the first half needs; the platform's retention, legal hold, and audit surface covers the second.
  • The overlap every program shares (consent governance, retention, sealed playback, audit) comes down to how the recordings are governed after capture, which is exactly where the platform's tenant-owned controls begin.

The buyer checklist

When you evaluate a recording foundation, ask these in order: the first three close the architecture question; the rest close the operations question.

  1. Is capture network-side? A desk-phone speaker or a conference bot misses SIP/trunk traffic; SIPREC capture on the carrier plane catches every SIP conversation, no device cooperation required.
  2. Are capture retries idempotent downstream? Recorders re-offer recordings after failures. Check that re-posts collapse to one artifact and one notification set, not a fan of duplicates.
  3. Is the join between capture and account provable? The recorder knows only session identifiers; the platform should resolve ownership through an indexed reverse map with a safe fallback, never through open-ended fan-out scans, and every join should be audit-logged.
  4. Do consent modes gate the recording start where you operate? One-party and all-party jurisdictions differ call by call; a consent mode per your owned numbers and per country resolution, plus IVR-captured receipts, should gate the start before media ever reaches the recorder.
  5. Can mid-call pause and resume work? PCI-DSS card capture and the occasional sensitive aside should be stoppable without dropping the call.
  6. Is retention set per your program? A platform-configured or tenant-configured age limit should delete media on schedule, with a webhook pre-delete signal (recording.retention_deleted) so your own archive mirrors it first.
  7. Can legal hold and sealing survive the sweep? A hold should exempt the artifact from retention entirely, and the integrity surface should let you seal, verify, and export a digest for counsel.
  8. Who answers the QC question? Automatic post-call scoring should flag silent/corrupt/abrupt artifacts and emit recording.qc_failed, so a bad capture pages you before a regulator's discovery request does.

Tenant-owned controls framing

The compliance rule on Devotel Orbit is explicit: the platform gives you the controls; whether a call may be recorded, how it is announced, and how long the artifact lives are yours to configure. In practice:

  • Recording consent enforcement is an opt-in switch under Settings → Compliance → Recording. When it is on, a recording start in an all-party-consent jurisdiction without an IVR-captured consent receipt is refused, and pause is never refused (a PCI-DSS capture break is always permitted). When it is off, recording is not gated; the obligations you carry are still yours, and the platform simply has not promised to enforce them for you. The DPA, BAA, and recording consent guide shows the full per-call consent trail, including verification and GDPR Article 7(3) withdrawal.
  • Retention is set per account. The sweep removes media past the configured age, nulls the playback pointer on the call record while keeping the auditable metadata (duration, price, transcript, status), and emits recording.retention_deleted ahead of the purge. A legal hold from the Recordings API exempts an artifact from the sweep entirely.
  • Playback and sharing ride behind short-lived signed URLs and explicit share links rather than public object paths, so a leaked link has an expiry measured in minutes or hours, not forever.
  • The audit layer writes each capture, join, hold, and playback event into a tamper-evident chain: the ledger an examiner actually reads, long after the regulator's question arrives.

Configuring this well is a tenant task; running it is the platform's. The brief for an examiner then stops being an engineering project.

Frequently asked questions

Is SIPREC the only way Devotel Orbit records?

No. It is the SIP/PSTN path. Browser-only video rooms and AI-agent rooms record through the platform's own media egress instead, and all three capture classes land in the same unified recordings store, under the same audit chain, with the same call.recording.ready lifecycle events.

Why are we not routing over WebRTC instead?

Because the capture point matters, not the transport detail. SIPREC lets the network record all SIP conversations with no client-side cooperation; WebRTC-side capture still depends on the far endpoint behaving. For a financial-recording or MiFID II program, "the network recorded it, device-independent" is the custody story that survives examination.

Does the recorder's session identifier equal my call ID in the dashboard?

Not always. The recorder only carries the carrier's session identifier, and the platform resolves it back to your account's call record at join time, indexing both the platform's call id and the carrier session id. You never handle the raw SIPREC identifiers; the dashboard and API talk in your call ids.

Does a recording.started webhook mean the recorder acknowledged the start?

It means the recording joined once. The recorder has no separate start callback, so the start, complete, and fail lifecycle events are all derived from the one ingestion callback, deduplicated so a retry re-posts nothing new. If you rely on the lifecycle for billing or downstream copies, that idempotence is the guarantee that keeps totals right.

Where do I read the retention and legal-hold surface?

The recording lifecycle operations guide covers legal hold, retention sweeps, and QC triage end to end; the Recordings API reference covers the endpoints your integration calls.

The takeaway

SIPREC's existence is old news. The protocol is a decade old, and the recorder-in-network idea is a generation older. But it is live news for a compliance buyer, because it is the standard way to answer the question those searches are really asking. Devotel Orbit's SIP-based recording already runs that shape: capture on the carrier plane, HMAC-authenticated ingestion, deterministic join to your call record, idempotent lifecycle events, automatic QC. On top of that sits the tenant-owned control layer (consent enforcement, retention, legal hold, signed playback, tamper-evident audit) that turns a recorded call into a supervision program rather than a file cabinet. The consent rules explainer covers the jurisdiction-by-jurisdiction start question; the attestation explainer covers the adjacent identity layer; and this one maps the capture layer you put both on top of.

Published 10 September 2026.

SIPREC call recording on a CPaaS: what it is, and why compliance buyers ask about it — Orbit by Devotel