Open Voice Shield FAQ

Yes, for operators who want the recording, the transcript and an action on the number with every verdict: one SIP hop that records every call, returns a fraud and TCPA verdict with the evidence, shows signalling and media while the call is up, and acts on the number's next call. The side-by-side, with sources and dates, is on the VeriSwitch SmartShield alternative page.

No. TCXC Open Voice Shield is TelecomsXChange's voice call fraud analysis service, at ovs.telecomsxchange.com. OVS is also the usual abbreviation of Open vSwitch, a virtual network switch unrelated to telephony, and VoiceShield is a call-monitoring product of FraudCentral LLC. Veridas Voice Shield, a voice deepfake check, is a fourth unrelated product. The FraudCentral comparison page sets the two call products side by side.

Yes. Our media server relays the RTP in both directions and captures it, and that capture is the recording. There is no mode in which Open Voice Shield analyzes a call without carrying its media.

It is a proxy, not a B2BUA. The dialog is authorized, record-routed and relayed onward, and the far end sees your own From and To. To a B2BUA or SBC, Open Voice Shield is the next SIP hop, so it works in front of one or behind one.

Any SIP-capable server: Asterisk, FreeSWITCH, 3CX, Cisco CUBE, AudioCodes and Oracle SBCs, softswitches and diallers all speak the same standard SIP that Open Voice Shield expects. There is no agent, SDK or proprietary trunk type, and your switch can stamp its own SIP headers on the INVITE, an account reference, a campaign id, and Open Voice Shield captures them onto the call record. See interoperability.

It is built as carrier-grade voice fraud prevention software: a SIP proxy in the signalling path and a media relay in the RTP path, IP-authenticated like an interconnect, with prefix routing, tech prefixes, credit cut-off by dialog timeout, TLS to voice agents, and a SIP ladder and packet capture kept per call. To your switch it looks like a carrier, including how it fails: unreachable means your own failover route takes the call.

Yes. A CCaaS platform or dialler is a SIP switch like any other: route the campaign, or a sample of it, through the hop and every analyzed call returns a fraud verdict and a TCPA compliance note with the recording and transcript. The TCPA page covers the contact-centre case.

Attestation and reputation work on the number at signalling time and never hear the call. Call analytics score recordings your own systems made. CDR-based fraud management sees destinations, volumes and patterns after the fact. Open Voice Shield is a SIP hop that makes the recording itself, reads the conversation, checks the route for false answer supervision and the audio per leg, and blocks or diverts the number on its next call. They are complementary. The comparison by approach is on the one-page case.

If your switch cannot reach the ingress, the INVITE times out and your own failover route takes the call, as it would for any carrier. If the ingress is up but its API is not, the call is answered 503, so your switch fails over immediately instead of waiting.

No. Open Voice Shield is an ordinary SIP hop, so your dial plan can route a random share of traffic through it, one call in ten or twenty, and spot-check instead of committing everything. Pay-as-you-go has no monthly fee and no concurrency limit, so a sample costs exactly the calls in it. If your switch cannot split traffic, let Open Voice Shield do it: route everything and set the destination to analyze 1 in N calls. The rest are recorded, not analyzed, and any of them can be analyzed on demand.

Media is passed through, and G.711 PCMU, G.711 PCMA, G.722, G.729 and G.723.1 are decoded for transcription and analysis. A call in Opus or another codec is relayed and billed normally, and records unsupported_codec instead of a transcript. Offer G.711, G.722, G.729 or G.723.1 on the leg you send us; G.711 transcribes best.

The spoken language is detected automatically on every analyzed call: English, Spanish, French and the other languages the transcription stage handles. Transcription and analysis run in that language with nothing to configure, and the verdict reads the same, so a Spanish scam call gets the same red flags and recommendation an English one would. The detected language is recorded on the analysis.

Yes. Each analyzed call records an estimated MOS (E-model), jitter and packet loss per leg, computed from the same media capture that produces the recording. The worst leg is shown on the call record and quoted in the alert email beside the verdict, and an alert rule can email you when a call's estimated MOS falls to a ceiling you choose. It is a transport-quality estimate derived from loss and jitter, not a perceptual audio score.

No. The media leg must be plain RTP, because encrypted media cannot be captured and decoded for transcription. The onward SIP leg can use TLS, and the portal and API are HTTPS.

One extra SIP hop and one extra media relay: the network time to and from our node, plus the relay itself. In standard mode no analysis runs during the call, so the fraud pipeline cannot delay live audio.

Outbound to the ingress on 5060 UDP or TCP for signalling, and RTP to the advertised media address on the published UDP range. Return media can arrive from any far-end address, so do not restrict the RTP range by source.

In standard mode, after the call ends: decode, transcription and analysis run as an asynchronous job, so the verdict appears on the call detail seconds after hangup. Realtime mode, set up on request at a higher cost, scores the call while it is still up. Measured end-to-end timings are available on request.

Yes. Every verdict is pushed by a signed call.analyzed webhook within minutes of hangup, alert rules post to Slack or e-mail, and the live-calls endpoint reports state and media statistics while a call is up. The API reference lists every endpoint. In standard mode the verdict itself is produced after hangup, on the completed conversation. Realtime mode, set up on request, produces it while the call is up.

Yes, in realtime mode, set up on request: the call is scored while it is still up, in time to cut or divert it. It costs more, because the whole call is transcribed and read as it happens. In standard mode the analysis exists once the conversation is complete, and the enforcement surface is the next call from that number, which an automation rule can block or divert for a window you choose.

Yes, two forms. Early-answer FAS: the route returns the answer while the far end is still ringing, so billing starts on ringback tone. The recording is measured after the answer for ringback or busy tone at the frequencies in use worldwide, and the route alert names the tone, how long it ran and whether anyone ever spoke. Delayed-playback FAS: a vendor answers legitimately and later switches the callee leg to a recorded playback to keep minutes running. The callee channel of the transcript is read for the switch. Both raise a route alert beside the verdict, separate from the caller's block / review / allow, and the PDF report carries it for the vendor conversation.

Yes. Any analyzed call can be re-run through a different model, a frontier model from Anthropic or OpenAI or an open-weight model through OpenRouter, to second-opinion a verdict. A re-analysis is never charged: the flat analysis fee applies once, on the first completed analysis.

The BYE ends the dialog. Deleting the media session flushes the capture, and the call end is reported with its duration, SIP code and reason. That report starts the decode, transcription and analysis pipeline.

We do not publish an accuracy, precision or recall figure: none has been computed against a labelled ground-truth corpus. We have measured end-to-end latency, per-stage timing and agreement between analysis tiers on the same calls, and we share them, with the method and raw data, on request.

By source IP against a per-tenant CIDR allow-list, checked on the initial INVITE. There is no registration and no digest credential. REGISTER is answered 403, because Open Voice Shield is not a registrar.

On our own disk, or in an S3-compatible bucket we control with server-side encryption and public access blocked. Nothing is written to storage we do not control.

Yes, per account. Recordings and media captures are kept in Canada by default; under Account > Data location you can choose the United States instead, for storage and for the media relay that carries your calls. Europe or any other region our cloud runs in can be enabled on request. The choice applies to calls from then on, recordings already stored stay where they are, and call records, transcripts and analyses stay in the platform database in Canada either way. Data location.

Recordings, media captures and SIP logs each have their own retention window. Expiry deletes the object rather than flagging it. Call detail records, transcripts, analyses and the audit log have no automatic deletion today.

Speech-to-text runs either on our own servers, where the audio never leaves them, or against a cloud API. Fraud analysis sends the transcript and call metadata to a cloud analysis API. Each call's detail page shows whether each stage ran locally or in the cloud.

Yes. Each call keeps its media capture and its traced SIP messages. Both download from the call detail, and both are in the offline analyst bundle with the report, the transcript and the recording.

The next call is refused at authorization with SIP 402. A call already up is capped by a dialog timeout computed from the remaining balance, so it cannot outrun its funding. During a pilot, balance gates are skipped, but security checks still apply.