SIP call fraud analysis: the Open Voice Shield white paper

Section 1

Scope, and who this is for

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 measured, and we share it with the raw data on request.

Three deployments use the same hop. A carrier or wholesale trunk routes a client, a prefix or a sample of traffic through it. A business phone system sends its calls through it on the way to and from its carrier, so every call in or out of the business is scored. A mobile operator places it as a node in the path of enrolled numbers, over SIP from the core or behind an SS7-to-SIP gateway for legacy signalling. The hosted service runs in Canada. An on-premises licence runs the same software on the operator's hardware with its own models, keys and storage.

Section 2

Threat model

What the service is designed to catch, what the adversary controls, and where the boundary of the design sits.

The adversary

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.

The harm

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.

The observation point

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.

Out of scope

Design boundaries as of 26 September 2026. Anything not listed as shipped is not claimed.
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. What it can do since v2.0 is prove delivery: a caller-ID check places a call through a route and reports what arrived (section 8).
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, mumble, 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 and G.722 are decoded natively. G.729 and G.723.1 are decoded offline after hang-up. Media the decoder cannot read is reported as an unsupported-codec error on that call rather than guessed at.
Sensitive values in transcripts	Card numbers, codes or account details spoken on a call are in the transcript as spoken. Redaction to typed placeholders is designed and not yet built. The portal masks phone numbers by default, and recordings and transcripts sit under the account's retention and audit controls (section 13).
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

Where it sits in the call path

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 dialog: 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.

Since v2.0 the ingress decides more per destination. Each destination carries a handling mode: full analysis, record only, or relay only (nothing recorded, the CDR is the record). It carries a sampling policy: analyze one call in N and record the rest for on-demand analysis, or, at the door, carry one in N and refuse the rest with 503 so the switch fails them over and nothing is recorded or charged. A whitelisted source IP can hold several sub-customers by dial prefix, stripped before the call goes on and stamped on the record. Destinations are monitored with SIP OPTIONS and show up or down with a round-trip time. And an account chooses its data location: the region whose relay carries its media and the region whose store keeps its recordings, Canada by default, the United States on request, with call records and analyses always in Canada.

Two operational behaviours matter to a NOC.

The ingress fails closed. If the authorization API cannot be reached, or returns something it cannot parse, the INVITE is answered 503 Service Unavailable, so your switch takes its normal alternate route instead of losing calls silently.
A prepaid balance is enforced as a per-call maximum duration, returned at authorization time. The dialog ends at the cut-off rather than running up an unbounded debt.

Signalling and media pass through; the analysis happens afterwards, off the call path.

Section 4

The pipeline, stage by stage

Five stages run after the dialog 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.

Pipeline stages. Measured stage latencies are available on request. This table describes what each stage does and how it fails.
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. The model is the tier's: OpenAI's whisper-1 or gpt-4o transcribe, Whisper large-v3 on Groq, or a faster-whisper on the worker for audio that must not leave the network.
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. Prompt v4 gates the score: a probability above 70 needs a hard sign in the transcript: a request for money, cards or codes, a threat, a deadline, impersonation or remote access. Absence of identification alone is not evidence.
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.

Three classes of model, chosen per tier

The transcription and analysis models are not fixed. The operator sets, per customer tier, which pair runs and what the tier's per-call fee is. The customer picks the tier on the dashboard, and every call record and ledger line names the tier it was billed under. Three classes are available: frontier commercial models (OpenAI, Anthropic), large open-weight models through OpenRouter (gpt-oss 120B, Llama 3.3 70B, Mistral Small 3.2, Qwen3, DeepSeek and others, routed by throughput so a verdict takes about a second rather than most of a minute), and models on the operator's own hardware (a local Whisper on the worker). Each call records the provider, the model and what the call cost. OpenRouter reports its real charge per call, and the others are priced from a table the operator can edit. The one per-call fee a customer pays covers both the transcription and the analysis.

The tiers as configured on the hosted service, 26 September 2026. An operator with its own licence sets its own.
Tier	Transcription	Analysis	Fee per call
Economy	gpt-4o mini transcribe	gpt-oss 20B via OpenRouter	$0.015
Power (default)	Whisper large-v3 on Groq	gpt-oss 120B via OpenRouter	$0.02
Max	whisper-1	Claude Sonnet 5	$0.05

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 measured 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 available on request.

Section 5

What a verdict contains

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.

Verdict fields, as returned per call.
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.
route_alert	object \| null	A finding about the route rather than the caller: early answer on ringback, or a mid-call switch to recorded playback (section 7).
qos	object	On the call record: estimated MOS, jitter and packet loss, overall and per leg, from the same capture (section 7).
ai_mode	economy \| power \| max	On the call record: the tier the call was processed and billed under (section 4).
sampled, sub_customer	bool, string	On the call record: whether the destination's sampling policy selected the call for analysis, and the sub-customer label from the dial prefix.

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

Acting on a verdict

Automation rules: Match on the verdict and act on the ANI: block it, or divert it to a destination you choose, for a window you set. This is where a verdict becomes enforcement.
Cases: Group calls into an investigation with an assignee, comments and e-mail notification, so a fraud team works a pattern, not a list of rows.
Alerts and webhooks: Alert rules deliver by e-mail, or to a Slack channel each customer connects to their own workspace, on conditions you define: the verdict, or the call's quality. Outbound webhooks are signed so your receiver can verify them, and go to a pre-validated address.
Balance and cost signals: A low balance alert fires once when the prepaid balance drops under a threshold the account sets, by e-mail and to its channels, and re-arms after a top-up. Monthly invoices list call minutes, the transcription-and-analysis fee per call, caller-ID checks and plan lines.
Sharing evidence: A read-only link with a per-link password shows a call to someone without an account. The export bundle packages report, recording, capture and SIP log for offline review.
Voice AI destinations: A destination can be an AI voice agent, OpenAI (GPT-Live-1 and Realtime) or xAI, reached over TLS with SRTP media while the switch sends plain SIP and RTP, so a divert rule can hand a known fraud caller to a machine that keeps them talking, and a legacy switch can reach a modern agent at all. When the agent transfers the caller, the platform places the new call itself, so a switch without SIP REFER still gets its transfer. A test call can be placed by one of the account's agents and hold a real conversation with whatever answers. Every such call is still recorded, transcribed and analyzed, and the agent leg is metered per second. Not part of the measured pipeline in section 11.

Why the unit of action is the call: the compliance dimension

The tcpa_comment field exists because telemarketing liability in the United States accrues per communication. Statutory damages under the Telephone Consumer Protection Act (47 U.S.C. § 227) run up to $500 per illegal call or text and up to $1,500 where the violation is willful or knowing, with no cap on the aggregate. FCC forfeitures can reach tens of thousands of dollars per violation. These are citations of the statute, not measurements of ours. A per-call compliance note, surfaced minutes after hangup and enforceable through the automation rules above, matches the unit at which that exposure accrues. The operational case is laid out on TCPA penalty prevention and the arithmetic on what one illegal call costs.

The comment is a reading of the conversation against TCPA / TSR concepts, not a legal determination, and nothing in this paper is legal advice.

Section 7

Route integrity and call quality from the same capture

The capture that feeds the fraud verdict also says how the route behaved and how the audio sounded. Version 1.2 reads both, per call, with no probe and no synthetic traffic.

False answer supervision, two forms

Early answer. A route that returns 200 OK while the far end is still ringing starts the billing clock before anyone picks up. After the answer, the callee channel is measured for ringback or busy tone with a Goertzel filter at the frequencies in use worldwide (400, 425, 440, 450, 480 and 620 Hz), in 100 ms frames, over the first minute. Sustained tone after the answer is reported as an early-answer route alert with the seconds of tone heard.

Delayed playback. The callee channel of the transcript is read for a mid-call switch to recorded playback: a live greeting followed by an announcement, a menu that never reacts, or an abrupt recording where a person was speaking. It is reported as a route alert with the leg and the moment of the switch.

A route alert is kept separate from the caller verdict. A test call to a bank can be allow for the caller and carry an early-answer alert for the vendor, and the two go to different people: the alert to the carrier relationship, the verdict to the fraud desk. The branded PDF report of the call carries both, for the vendor conversation.

Between calls, every destination is probed with SIP OPTIONS and shown up or down with its last round-trip time, so a route that has died is known before a customer's call finds out.

Estimated call quality per leg

From the RTP itself: packet loss from the sequence numbers, jitter from the arrival timing, and an estimated MOS from the E-model, for the caller leg and the callee leg separately. A route where the far end degrades shows a low callee-leg score while your own side stays clean, which points at the vendor rather than at your switch. The figures are estimates from loss and jitter, never measured opinion scores, and are capped by the codec: about 4.4 for G.711.

The call quality panel of a call record: estimated MOS, jitter and packet loss, overall and for the caller and callee legs. — Quality per leg on the call record, from the same capture as the verdict.

A route alert on a call record: early answer detected, with the seconds of ringback heard after the 200 OK and the leg it was measured on. — An early-answer route alert, separate from the caller verdict.

A Slack message posted by an alert rule: the verdict and probability in the headline, summary, category, entity, dialed number, caller ID, estimated MOS, red flags and an Open the call button. — An alert rule delivering to the customer's own Slack channel.

Section 8

Caller-ID verification and hosted numbers

Attestation says who signed a caller ID. Delivery is a different question: does the number you send arrive intact at the far end of a given route? Since v2.0 the platform answers it with a call.

A check places a short call through the customer's chosen destination, presenting the caller ID they want to prove, to a verification number the platform holds in the requested country. The number answers, reads the caller ID the carrier delivered, and the platform compares it with what was sent. The result is one of five words: match, modified (format, prefix or digits changed, with the sent and received numbers side by side), withheld, missing, or not_received (the call never reached the number). The check carries the call's post-dial delay, answer time, SIP ladder and estimated audio quality, because a route that mangles caller ID often misbehaves in other ways too.

Checks run once, from the portal, the API or the verify_cli tool, or on a schedule per route with an alert when a result changes. Each is priced per check plus the short call it places. Coverage is by country. A country not yet covered can be requested, and the requester is told when its numbers go live.

Hosted numbers

The verification numbers are, in part, the community's. Anyone who owns a working number in a wanted country (mobile, landline or toll-free) can point it at the platform's SIP ingress, call it once so the platform can read what the carrier delivers, and from then on earn a credit for every check that reaches it. Checks are about twelve seconds long, never overlap on one number, and only occur while a check holds it. A number that stops answering is paused until its owner tests it again. Numbers in Africa, the Middle East and Asia are the most wanted.

The route is judged by the caller ID that arrived, not by what was signed.

Section 9

Operating the platform from an agent

Everything the console does is an endpoint, and since version 1.2 an AI agent can run an account through to a verdict: configure, ask for a call, read the result. A person signs in to connect the agent and confirms each test call it asks for. Version 2.0 adds caller-ID checks, hosted numbers, live transfers and a Claude plugin that packages the server with four skills.

Three things make that possible. Discovery: a description of the service at /llms.txt, an agent card at /.well-known/agent.json and the full contract at /api/openapi.json, so an agent that lands on the origin needs no HTML. An MCP server at /api/mcp: twenty-seven tools over Streamable HTTP, each a thin wrapper on one REST endpoint, each declaring an output schema taken from that endpoint's OpenAPI response, so results are typed data an agent can validate and diff, never prose it has to parse. Test calls: the platform originates a call through the account's own destination and plays a speech sample, a neutral announcement or a known scam script, so a route can be exercised without a switch. Every test call opens with a recorded announcement that it is an automated test call placed on behalf of an account holder and that it is recorded. It presents the platform's own number or one of the account's verified numbers, which a person proves in the portal by answering a code call, and the scam script rings only verified numbers. Asked for through the MCP server, a test call waits until a person confirms it on a portal page the agent links to.

Authentication follows the MCP authorization specification. The endpoint starts open. The first tool that needs an account answers 401 with a WWW-Authenticate challenge, and an OAuth-capable client registers dynamically, sends the person to a consent page that is the sign-in or the sign-up itself (passkey second factor included), and continues with a rotating token. A client that holds an API key sends it as a bearer header instead. Credentials are never tool arguments, and secrets such as a destination's password or the webhook signing secret are entered in the portal, never in the conversation. Every write an agent makes lands in the account's audit log under the key that made it.

The interface is the same whichever client an agent runs in: a chat assistant with the server added as a connector, an editor agent, a coding agent on the command line, an agent built on a model API, or a hosted managed agent with its credential in a vault. The agent guide has the install step for each. For Claude there is a plugin: the connector plus skills for onboarding, route testing, fraud review and caller-ID verification, installable from its repository. On the Linux desktop an Omarchy bar plugin puts the day's high-risk verdicts and live calls beside the clock.

Whichever door the agent uses, it goes through the same authorization path, audit log and rate limit.

get_call, trimmed: what an agent reads back after a test call

{
  "status": "completed", "origin": "test", "billsec": 30, "codec": "PCMU",
  "pdd_ms": 3180, "answer_delay_ms": 8258, "hangup_by": "callee",
  "analysis": {
    "probability": 5, "category": "robocall", "recommendation": "allow",
    "red_flags": [], "route_alert": null,
    "summary": "An automated route test from Open Voice Shield; the callee acknowledged and hung up."
  },
  "qos": {
    "mos": 4.4, "packet_loss_pct": 0.0, "jitter_ms": 0.17,
    "legs": {
      "caller": {"mos": 4.4, "packets": 1039, "lost": 0, "jitter_avg_ms": 0.04},
      "callee": {"mos": 4.4, "packets": 1286, "lost": 0, "jitter_avg_ms": 0.17}
    }
  }
}

A real test call to the author's mobile, as returned by the API. Every field is typed in the tool's output schema.

Section 10

A voice NOC agent that tests routes around the clock

A reference design for an agent that tests every destination and trunk around the clock, judges the result against what is normal for that route, and wakes a person only when something moved. It judges with the tools in section 9. The calls themselves come from a scheduled script with an API key on the REST API: through the MCP server every test call waits for a person's confirmation, which suits a request, not an hourly probe.

The loop, as tools. Requiring a second call before any alert keeps it quiet.

What it checks, and what "normal" means

Accuracy here comes from comparing a route with itself. The agent keeps, per destination, the last seven days of results from list_calls with origin=test and a from window, and judges each new call against those, not against a global constant. The thresholds below are starting points. A route with a satellite hop has a different normal from one across town.

Checks per test call, with starting thresholds.
Signal	Field	Raise when
Reachability	sip_code, answered	Anything but 200, or no answer within 60 s, twice in a row.
Post-dial delay	pdd_ms	Above 8 s, or double the route's 7-day median.
Answer delay	answer_delay_ms	Known IVR answering later than its usual few seconds.
Early answer	analysis.route_alert	Present, of type early_answer_fas. One occurrence is worth a case.
Callee-leg quality	qos.legs.callee	Estimated MOS under 3.6, loss over 1 %, jitter over 30 ms, or a drop of 0.4 MOS from the route's median while the caller leg stays clean.
Audio flowed	qos.legs.*.packets	Either leg far below 50 packets per second of billsec.
Announcement heard	transcript	The caller channel does not contain the sample's own words: audio was lost, transcoded badly or cut.
Codec	codec	Changed from what the route negotiated last week.
Caller ID delivered	verify_cli	A scheduled check on the route returns anything but match.
Billing	billsec	Charged seconds far from the seconds requested plus the opening announcement.

Design rules that keep it accurate

Confirm before alerting. A single bad call is a data point, and two in a row are a signal. Networks flap.
Dial numbers you own or an IVR you know. A known answering point gives a stable answer delay and a callee channel whose content the agent can check. Leave the caller ID to the platform's own number, or give one of the account's verified numbers; no other is accepted.
Keep the calls short and the cadence modest. Twenty seconds per route per hour is enough for the route figures and costs well under a dollar a day per route at pay-as-you-go rates. The analysis fee is per call, so fewer, longer calls beat many short ones when you also want a verdict.
Separate the route from the caller. The verdict on a route test is always allow. The route alert and the quality figures are the news. Read route_alert and qos, not probability.
Let the platform hold the evidence. A case with the PDF report and the export bundle is what a carrier will act on. An alert with a number is not.
Stay within a budget. Prepaid balance is the natural ceiling. The agent should read account_balance before a run and stop, not degrade silently, when it is low.

A hosted agent definition: the server, the tools it may use without asking, and the ones it does not need

{
  "name": "Voice NOC",
  "mcp_servers": [
    {"type": "url", "name": "open-voice-shield", "url": "https://ovs.telecomsxchange.com/api/mcp"}
  ],
  "tools": [
    {"type": "mcp_toolset", "mcp_server_name": "open-voice-shield",
     "default_config": {"permission_policy": "always_allow"},
     "configs": [
       {"name": "place_test_call", "enabled": false},
       {"name": "cancel_test_call", "enabled": false},
       {"name": "whitelist_ip", "enabled": false}
     ]}
  ]
}

The credential is an API key held in the agent platform's vault; the agent never sees it. Placing calls is switched off because the scheduled script places them. The agent reads and judges.

What this design does not claim: it measures how a route behaves for a test call it placed, not how every customer call fared. It sees the routes it dials, at the cadence it dials them, and its quality figures are estimates from loss and jitter. Its value is that a person is told about a route that changed, with the evidence attached, by the time they sit down, and that the same tools let that person ask the agent to look deeper.

Section 11

What we measured

Method, corpus and raw data are available on request.

Measured figures are not published at present. Latency, transcription error against a known script and inter-tier agreement have all been measured on a development machine. We share the method, the corpus and the raw results on request.

How the open-weight tier was chosen

Before an open-weight model became the default analysis model, each candidate ran the same labelled set of synthetic scam and legitimate transcripts plus a handful of real calls from the platform, and its verdict, category and probability were compared with the frontier models in use. A separate model then scored every written analysis blind, shuffled and anonymised, for how well its red flags quoted the call and how faithful its summary was. The candidate that agreed with the frontier verdicts on the real calls, wrote evidence the judge rated close to the frontier models, and answered in about a second through the fastest hosts became the default. Transcription providers were compared the same way, by word error rate against scripted calls.

Two limits. The labelled set is small and written by us, so it ranks models and cannot yield an accuracy figure. Agreement with a frontier model is agreement, not truth. The harness (app/scripts/eval_verdicts.py) ships with the platform so an operator can run the same comparison on their own labelled calls.

Section 12

What we have not measured yet

The known gaps as of version 2.0.

Detection accuracy on real fraud. No accuracy, precision, recall or false-positive rate is published, because we do not have a labelled corpus of real fraudulent and legitimate calls. Our corpus is synthetic and written by us, so any rate computed on it would measure our own script writing.
Multilingual performance. Everything measured so far is English. Transcription and analysis both accept other languages, and neither has been benchmarked in one.
Adversarial evasion. We have not tested a caller who deliberately evades transcription or scoring: code switching, mumbling, moving the ask to SMS, or splitting a script across several short calls.
Throughput at scale. Stage latencies here are single-call measurements on one machine. Sustained throughput, queue behaviour under a hangup burst and concurrency limits are not yet benchmarked.
Audio quality effects. Packet loss, jitter, low-bitrate transcoding upstream, hold music and IVR audio all affect transcription. The corpus is clean synthesized speech, so it does not exercise any of that.
Route monitoring at scale. The voice NOC design in section 10 has been exercised on a handful of routes and numbers. Its thresholds are starting points; no figure for its own false-alarm rate is published yet.
Sensitive values in transcripts. Card numbers, codes and account details spoken on a call are transcribed as spoken. Redaction to typed placeholders before analysis and storage is designed. Until it ships, the controls are retention, access and the audit log.
Open-weight verdicts over time. The open-weight default was chosen on a small set and a handful of real calls. Its agreement with frontier verdicts across a month of production traffic has not yet been measured, and hosts behind OpenRouter change.
Mobile-operator scale. The node-per-region topology has carried carrier and business traffic. It has not been exercised at the call rates of a large mobile subscriber base.
Long-run verdict stability. Analysis models are updated by their vendors. We have not yet run the same corpus over time to quantify how much a verdict drifts when a model version changes.

Section 13

Handling of recordings and evidence

Recordings and captures are stored in a bucket we control with server-side encryption and public access blocked, in Canada by default. An account can choose the United States for its storage and for the relay that carries its media, and other regions on request. Call records, transcripts and analyses stay in the platform database in Canada whatever the choice. Retention windows are enforced with real deletion. Every endpoint scopes a call to its own tenant, phone numbers are masked in the portal until revealed, and security-relevant actions go to an audit log against the acting user. An on-premises licence keeps all of it on the operator's hardware.

The full control list is on the security page: ingress authentication, credential handling, webhook signing and SSRF protection, share-link protection, rate limiting.

Section 14

Reproducing this

The harness, the corpus and the raw result file are kept so the numbers can be checked rather than believed: the corpus carries a SHA-256 per file, and the exact command, the hardware and the per-call results behind every aggregate travel with it. Ask us and we will send the lot.

Document v2.0, published 27 August 2026 and revised 6 and 26 September 2026 by Open Voice Shield. Figures dated where they appear. Corrections: support@telecomsxchange.com.