Signalling, media and the pipeline
How a call travels through Open Voice Shield
Your switch sends the INVITE to the Open Voice Shield ingress as an ordinary SIP hop. We authorize it by source IP against your whitelist, relay the RTP through our media server, capture it to a pcap and route the call on to your own destination. After the BYE we decode the capture to a stereo WAV, transcribe it, analyze it and attach a block, review or allow verdict to the call.
OVS is in the media path — say it plainly
The RTP goes through our media server in both directions. That is how the call gets recorded; there is no recording without it. If you need a fraud service that never touches your audio, this is not that product.
The diagram
The path, end to end
There are two halves. While the call is live, OVS 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: OVS 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 dialed 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.
| 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 dialed 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.
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.
| 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 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 on the benchmark page.
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.
Nothing to install, no client to run. If your switch can send a call to a carrier, it can send a call to OVS.