Skip to main content

CALEA Lawful-Intercept Provisioning

Orbit provides provisioning and an auditable workflow only. This surface does not capture calls, tap media, wire a carrier, or hand anything to a law-enforcement agency. Activating an order records that the intercept is authorized and running within its warrant window — nothing more. Actual capture and delivery to a law-enforcement collection function is a softswitch / mediation concern, out of scope for this page. This page is not legal advice; confirm your lawful- intercept obligations with qualified counsel.

What CALEA is

The Communications Assistance for Law Enforcement Act (CALEA, 47 U.S.C. §§ 1001–1010) obligates carriers that route voice and SMS to be able, on a court-authorized warrant, to provision an intercept against an identified target. Orbit routes carrier-grade voice and SMS through the Devotel wholesale softswitch, so your organization may be served with lawful-intercept warrants and must be able to answer them. Two capture scopes exist:
  • Pen register / trap-and-trace — call-identifying information only (dialled or received digits, timestamps, routing, signalling). No call content.
  • Title III intercept — call-identifying information plus call content (the audio of the call).
The warrant names the scope it authorizes; only a Title III order permits content capture.

Why the register exists

A warrant can arrive at any time, from any authority, naming any of your numbers. When it does, you need a single register that answers three questions with evidence: what was requested of us, who inside the organization authorized and ran it, and was it ever live outside its authorization window? The intercept order register answers those questions. Each order records the authorizing warrant metadata — court order reference, issuing authority, requesting law-enforcement agency — the capture scope, and the authorization window, then moves through a guarded lifecycle with only valid forward transitions. Every create and every status change writes an audit-log entry, and every read returns a live verdict on whether the order is inside its authorized window. All write endpoints are gated behind the owner or admin role; reads are authenticated and tenant-scoped. Order records are stored per-organization; one organization can never see another’s orders.

Intercept order lifecycle

An order moves through exactly one path forward: requestedauthorizedactivesuspendedterminated
  • requested — the warrant has been logged; internal legal review is pending.
  • authorized — legal review confirmed the warrant; the order is ready to activate.
  • active — the intercept is provisioned and recorded as running, inside its warrant window.
  • suspended — temporarily paused; it can resume to active.
  • terminated — torn down. Terminal; the order can no longer change.
Allowed transitions: Anything else returns 409. You cannot skip a state (for example, activate from requested without an authorization step) and you cannot mutate a terminated order.

Log an intercept order

Required body fields: Optional: issuing_authority, law_enforcement_agency, notes (each string, bounded length). A bad payload returns 422 VALIDATION_ERROR with the failing fields. A 201 response returns the new order — the server derives a captures_content flag from the scope (true only for title_iii), stamps the lifecycle timestamps, and attaches a live warrant_window verdict:

Authorize the warrant

Legal review confirms the warrant is valid; this records that decision:
Only valid from requested; otherwise 409. notes is optional (≤ 2000 chars). Returns the order with status: "authorized" and authorized_at stamped.

Activate the intercept

Marks the intercept as provisioned and running — and checks the warrant window first:
Only valid from authorized or suspended. Activation refuses an expired or unevaluable warrant window (409) so an intercept can never be marked running outside its authorization. A valid activation returns the order with status: "active" and activated_at stamped (activated_at is set on the first activation and kept through later suspend/resume cycles).

Suspend an intercept

Pause an active order; it can resume later:
Only valid from active; otherwise 409. Returns the order with status: "suspended" and suspended_at stamped.

Terminate the order

Tear the order down with a recorded reason. Terminal:
termination_reason is one of completed (investigation concluded), warrant_expired, warrant_revoked (court quashed the order), rejected (internal legal review rejected the warrant), or withdrawn (the requesting agency withdrew). Valid from any non-terminal state. Returns the order with status: "terminated", terminated_at stamped, and termination_reason set.

List and read orders

  • GET /compliance/calea/intercepts — every order for your organization, newest first, as { data: { orders: [...], total: n } }.
  • GET /compliance/calea/intercepts/{id} — one order, or 404 CALEA_INTERCEPT_NOT_FOUND if the id does not belong to your organization.
Every order on both endpoints carries a live warrant_window verdict, recomputed at request time. Error responses use the standard envelope: 422 VALIDATION_ERROR on a bad payload, 404 CALEA_INTERCEPT_NOT_FOUND on an unknown id, 409 CALEA_INTERCEPT_INVALID_TRANSITION on an out-of-order lifecycle move.

Warrant-window maths

A Title III intercept typically carries a bounded authorization — commonly a 30-day window that must be renewed by a fresh court order before it lapses. The register evaluates that window on every read so you can see at a glance whether a given order may still be running. warrant_window.status values: The verdict also returns expired and in_window booleans, hours_remaining until the window closes (negative once expired — null when the window cannot be evaluated), and a human-readable reason for the audit trail. Two requests a minute apart can report different verdicts on the same order — the verdict is computed live, not stored.

Provisioning and audit only — the hard boundary

Hold this boundary whenever you operate the register:
  • Activating an order records that the intercept is authorized and running within its window. Orbit does not capture calls, does not tap media, does not place a call, does not send a message, and does not wire a carrier.
  • Any actual capture and delivery to a law-enforcement collection function happens in the softswitch / mediation layer, outside this surface.
  • What Orbit does guarantee on this surface: records are organization-scoped and write-access is restricted to owner/admin; lifecycle transitions are guarded (you end with evidence of exactly which states the order passed through); activation is refused once the warrant window is closed; and every state change is written to the audit log with the warrant reference, the acting user, and the time.
When a warrant expires, terminate the order with reason warrant_expired. When a court renews it, log a new order for the renewed window rather than stretching the old one — the warrant reference and window must match the document in force, and a fresh order keeps that chain of evidence clean.