Technical white paper · v1.0 · 27 August 2026
Open Voice Shield is a SIP pass-through service. Your switch sends the call through it as an ordinary hop, and the media is relayed and captured. After the call clears, the audio is transcribed and scored, and the platform returns block, review or allow with the reasons behind it. This paper covers the threat model, where it sits in the call path, what each pipeline stage does, what we measured, and what it does not do.
Section 1
This paper is written for the people who will deploy it: NOC engineers, call-centre operations managers, and carrier or wholesale voice teams. It assumes you read SIP ladders, know what a pcap is, and will not accept a claim without a method behind it.
Two rules govern every number on this site. We publish only figures we measured, with sample size, date and hardware attached. And we publish no fraud-detection accuracy, precision or recall figure, because we have no labelled corpus of real fraudulent and legitimate calls. What we can show — latency, transcription error against a known script, and how far independent analysis tiers agree on the same calls — is on the benchmark page, with the raw data.
Section 2
What the service is designed to catch, what the adversary controls, and where the boundary of the design sits.
A human or scripted caller placing outbound calls through a trunk you operate or terminate. They control the caller ID they present, the script they read and how long they stay on the line. They do not control your switch, and do not know the call is being analyzed.
Impersonation of a bank, card issuer, government agency, utility or tech-support desk. Harvesting of card numbers, security codes, bank details or one-time codes. Prize and debt-collection pressure. Telemarketing that ignores identification, purpose and do-not-call rules. For the operator carrying the traffic, the harm is regulatory exposure and terminating-carrier complaints as much as the victim's loss.
A pass-through hop sees the signalling and, because the media is relayed, both audio directions on separate channels. It sees nothing the parties did outside the call. It decides after the call clears, so it protects the next call, not the one it just heard.
| Not addressed | Why, and what an operator should do instead |
|---|---|
| Stopping the call in progress | The verdict exists after the call clears. Enforcement applies to later calls: an automation rule can block or divert an ANI for a chosen window as soon as a verdict lands. |
| Caller-ID attestation | The platform records the ANI presented and reasons about the audio. It does not validate or issue a signed attestation. Keep your existing attestation controls. |
| Synthetic-voice and voice-clone detection | Not implemented. Analysis reads what was said, not how the voice was produced. |
| Adversarial evasion | A caller who knows they are being transcribed can code-switch, whisper, use jargon or push details to SMS. We have not measured how far that degrades a verdict. |
| Codecs beyond G.711 | G.711 A-law and µ-law are decoded natively. Media the decoder cannot read is reported as an unsupported-codec error on that call rather than guessed at. |
| Content the call never carried | No enrichment from external reputation feeds, credit data or social sources. The verdict rests on this call's audio and its metadata. |
Section 3
The ingress is an ordinary SIP hop. Your switch sends it the INVITE. The source IP is matched against the per-tenant allow-list, routing is by prefix so a tech prefix or a dialled range selects the destination, and the INVITE is relayed to the destination you configured — usually your own equipment or your onward carrier. No back-to-back user agent invents a new dialogue: the far end sees your call, not ours.
Media is relayed so it can be captured, one capture per stream. That is what makes a two-channel recording — caller left, callee right — possible without conferencing or injection. Nothing is played into the call, and no audio is added, removed or transcoded on the way through.
Two operational behaviours matter to a NOC.
Section 4
Five stages run after the dialogue ends. Each is a queued job, so a burst of hangups queues rather than dropping work. A transient failure is retried with backoff; a configuration error fails the call's analysis at once, and says why.
| Stage | Input → output | Failure behaviour |
|---|---|---|
| 1. Capture | Relayed RTP → one capture per media stream, kept with the call | No capture found after three retries marks the call failed with recording_not_found, rather than analyzed from nothing. |
| 2. Decode | Capture(s) → stereo 8 kHz 16-bit recording, caller left, callee right | Timing is rebuilt from RTP timestamps, so loss and silence suppression become silence rather than drift; unreadable payload types stop the call with unsupported_codec. |
| 3. Transcribe | Recording → speaker-labelled transcript with per-segment timestamps | Each channel is transcribed separately, which gives reliable CALLER: / CALLEE: attribution instead of guessed diarization. Silent channels are skipped. |
| 4. Analyze | Transcript + call metadata → structured verdict (schema below) | The declared JSON schema is required. A refusal or unparseable answer becomes a review verdict, never a silent allow. |
| 5. Deliver | Verdict → stored record, signed webhook, alert email, case, share link | Webhook delivery is signed and retried. A webhook that cannot be delivered never blocks the verdict from being stored. |
Why the analysis is fixed work, not per-minute work
Transcription scales with call length. Analysis does not: it reads a transcript, not audio, and most of its input is fixed instructions. In the benchmark run, analysis latency across calls of 40 to 73 seconds stayed inside one band per tier, while transcription time tracked call length directly. That matters when you size a queue. Per-tier figures are on the benchmark page.
Section 5
Every analyzed call produces the same structured record, returned by the API, sent to your webhook and rendered in the console. Nothing in it is free-form except the fields typed as prose.
| Field | Type | Meaning |
|---|---|---|
| recommendation | block | review | allow | The action the platform recommends for this ANI. |
| probability | integer 0–100 | How likely the call is a scam or unlawful telemarketing. |
| category | enum | Card scam, tech-support scam, government or bank impersonation, debt collection, prize or lottery, utility, compliant or non-compliant telemarketing, robocall, legitimate business, personal, unknown. |
| entity | string | The organization the caller claimed to represent; empty if they named none. |
| caller_identity | string | The identity the caller stated for themselves. |
| red_flags | string[] | Numbered observations, each tied to something said on the call. |
| tcpa_comment | prose | Identification, purpose, opt-out handling and misrepresentation, in TCPA / TSR terms. |
| summary | prose | What happened on the call, in a few sentences. |
| title | string | A one-line description usable as a case title. |
| language | string | Language code detected for the conversation. |
| keywords | string[] | Terms that drove the classification, for search and rules. |
Alongside the verdict, the call keeps its recording, its speaker-labelled transcript with timestamps, its SIP ladder and its capture, so an analyst can check the reading against the evidence. All of it downloads as one offline bundle.
Section 6
Section 7
The headline results are here. Method, corpus and raw data are on the benchmark page.
Measured 27 August 2026 on a development machine, with the tiers reached over a normal internet connection. Hardware, method, sample sizes, the per-call table and the raw data file are on the benchmark page. These are that machine's numbers, not a production service level.
Section 8
Stated plainly, because for this audience an honest gap is worth more than a confident number nobody can reproduce.
Section 9
Recordings and captures are stored on the operator's own disk, or in a bucket the operator controls with server-side encryption and public access blocked. Retention is configurable, and expiry is real deletion. Every endpoint scopes a call to its own tenant, and security-relevant actions go to an audit log against the acting user.
The full control list is on the security page: ingress authentication, credential handling, webhook signing and SSRF protection, share-link protection, rate limiting.
Section 10
The harness, the corpus and the raw result file are published so these numbers can be checked rather than believed. The benchmark page lists the corpus with a SHA-256 per file, the exact command, the hardware, and the per-call results behind every aggregate.
Document v1.0, published 27 August 2026 by Open Voice Shield. Figures dated where they appear. Corrections: support@telecomsxchange.com.