Signalling, media and the pipeline

How a call travels through Open Voice Shield

Open Voice Shield sits between your switch and your carrier as one SIP hop. Your switch sends each call to it first, as to any carrier. It checks the call comes from your whitelist, passes the audio through while recording it, and sends the call on. After hangup it transcribes the recording, reads it, and marks the call block, review or allow.

Open Voice Shield is in the media path

The RTP goes through our media server both ways. That is how the call is recorded. If you need a service that never touches your audio, this is not it.

The SIP ladder of one call in the portal: INVITE from the customer switch to the ingress, the relay to the destination, provisional and 200 OK responses, ACK, and the BYE that ends the dialog, each message expandable to its full SIP detail. — One call's SIP ladder, kept on every call record. Open it to see what happened on the wire.

The diagram

The path, end to end

Signalling and media through the ingress, then the post-hangup pipeline. Nothing is injected into the live audio.

There are two halves. While the call is live, Open Voice Shield behaves like any transit proxy: authorize, anchor the media, relay onward, tear down. Once the call is over, the work is asynchronous: decode, transcribe, analyze, notify. The halves are separated so a fault in the analysis half can never affect a live call.

Every routing decision is written to the log with an OVS: prefix, so you can read the reasoning behind any call.

While the call is up

Step by step, from INVITE to BYE

1. Your switch sends the INVITE

You point a trunk, route or carrier entry at the ingress host and port shown on your Network page. The initial INVITE must carry SDP. One without it is answered 488. Out-of-dialog OPTIONS is answered 200 OK, so your keepalive works as usual. REGISTER is answered 403: Open Voice Shield is a proxy, not a registrar.

2. We authorize it by source IP

The proxy asks the API to authorize the call, passing the source IP, the Call-ID, the From user, the dialled number, the From tag and any configured captured headers. The API matches the source IP against your CIDR allow-list, checks account state, the concurrent-port limit and the balance, then creates the call record and resolves the destination. The From tag separates a retransmission from a new call that reuses a Call-ID.

What the caller sees when authorization refuses the call.
Condition	SIP response	In the CDR
Source IP not whitelisted, or account suspended	403	no call record is created
Insufficient prepaid balance	402	no call record is created
Concurrent port limit reached	486	no call record is created
ANI under an active block control	403	blocked_by_rule
API unreachable or answering badly	503	no call record is created
Destination is loopback, link-local or the proxy itself	403	call failed
Media relay unavailable, or the onward leg cannot be reached	503	call failed

3. The media server anchors and records the media

Before relaying, the proxy hands the SDP to the media server with recording switched on. The media server rewrites the connection information so both parties send their RTP to it, and writes one pcap per media stream. Re-INVITEs and UPDATEs take the same path, so a mid-call codec or address change stays in the capture.

4. The call is routed on to your destination

The destination comes from your own configuration, in this order: the routing rule whose prefix matches the dialled number by longest match; the destination attached to that whitelisted IP; your account default; otherwise back to the source IP. A tech prefix, if the destination has one, is prepended to the Request-URI user just before relay. The proxy record-routes and relays, and tracks the dialog for credit cut-off and teardown. The call is proxied, not re-originated.

5. Hangup

A BYE from either side ends the dialog. The proxy tears down the media session, which flushes the capture, and reports the call to the API with the duration, the SIP code and the reason. If the call hits the credit or dialog limit instead, the proxy sends BYE to both sides and reports reason timeout. Either way, the second half now begins.

Watching it happen

The line inspector

Everything above is visible while it happens. On the Live page every licensed port is an indicator. Click a lit one and the inspector for that call opens beneath the bank.

The port bank with one lit port, and beneath it the line inspector for that call: caller and dialled number, connected, elapsed and credit clocks; a media path with packets flowing along the caller and callee legs; per-leg packet counts and rate; the SIP ladder with INVITE, 180 Ringing and 200 OK; codec PCMU, post-dial delay 17 ms, answered after 328 ms. — A call in progress, seen from the customer portal. The ladder is the proxy's trace. The post-dial delay and codec are read from it the moment the 180 and 200 arrive. The media lanes and packet counts come from the relay while the call is up.

The full tour

Six minutes, start to finish

A recorded walk through the customer portal: a live call on the port bank, the verdict on a real scam call, the recording and transcript, quality per leg, alerts, automation, connecting a switch, the API and billing. Every screen is the real product and every call is a real call.

The Live page of the customer portal during the tour: the port bank with one lit port and, beneath it, the line inspector for that call with the media path, the SIP ladder and the caller and callee leg cards. — Recorded from the customer portal on 2 September 2026. Plays from YouTube's privacy-enhanced domain, and nothing loads from YouTube until you press play.

After the call has ended

Decode, transcribe, analyze

This runs on a worker, not in the signalling path. A failure here marks the analysis failed with a readable error. It never affects a call.

The post-hangup pipeline and what fails in each stage.
Stage	What it does	Failure mode
Locate	Finds the captures for that call on the node that recorded them, retrying with backoff.	recording_not_found
Decode	Groups RTP by stream, decodes G.711 to PCM, reconstructs timing from RTP timestamps, writes a stereo 8 kHz WAV. Earliest stream left, the other right.	unsupported_codec:<pt>
Transcribe	Transcribes each channel separately, merges by start time, labels every line caller or callee.	job failure with the provider's error
Analyze	Sends the labelled transcript and call metadata to the analysis engine under a strict JSON schema, then stores the verdict.	job failure; a refusal is stored as review
Deliver	Charges the analysis fee, evaluates alert and automation rules, POSTs the webhook.	alert recorded as failed; webhook retried

A completed call detail: a 98% bank-impersonation verdict titled "Fake card fraud-department scam requesting card number and CVV" with a Block badge, the claimed entity, ten numbered red flags and a TCPA comment on the left; the stereo recording player and the caller/callee-labelled transcript on the right. — What the Analyze stage leaves on the call: the verdict beside the recording and the channel-separated transcript it was scored from, so the reading can be checked against the evidence. Seeded demo account.

The Analyze stage reads both channels, not just the caller's. On the callee channel it checks for a mid-call switch from interactive conversation to looping or non-responsive playback, the delayed-playback form of false answer supervision, where a route's vendor swaps the callee for a recording to keep minutes billing. A call showing that switch carries a route alert beside its verdict, aimed at the vendor serving the route rather than at the caller. How delayed-playback FAS detection works.

A call shorter than the configured minimum is marked skipped, not analyzed. The verdict schema, field by field, is on the features page. Measured end-to-end timings are available on request.

The calls list: each row carries the dialled number, the caller, when the call started, how long it lasted, and its risk score with the recommendation, so a high-probability block stands out from an allowed call. — Where the verdict lands. Each analyzed call carries its probability and recommendation, so the ones worth opening stand out in the list.

The same inspector after hang-up: the call marked ended by the caller, estimated MOS 4.40 on both legs with 0.9 ms jitter and no loss, the three pipeline stages decode, transcribe and analyze completed, and the verdict: block, 95%, a fake credit fraud department scam, with a summary of the call. — The same panel a minute after hang-up. The relay's live counters give way to the jitter, packet loss and estimated MOS of each leg, the three stages complete in turn, and the verdict lands where the call was, with a link to the record.

Getting connected

What you configure, once

Whitelist your SIP server's public IP. A CIDR per entry. Overlapping entries across tenants are rejected.
Add the destination we forward to, host, port and transport of your switch or carrier.
Point a trunk at the ingress shown on the Network page, with a copy button next to it.
Optionally add routing rules if different prefixes should go to different destinations.
Place one test call and watch it appear in the live view, then in the CDR with its verdict.

There is no software to install and no client to run. If your switch can send a call to a carrier, it can send a call to Open Voice Shield.

Start free with $5 credit Operator FAQ

No card is needed to create an account. The getting started guide walks through all eight steps, from whitelisting an IP to the first test call. For volume pricing, a security review or an invoice, talk to us first.