Docs Login

BLADE for Oracle Communications · Open source

Integrate your app into the Oracle Communications stack.

Oracle Communications runs the call. BLADE is the layer that lets a capability the stack doesn't have plug straight into that call: your service, another vendor's, or a system the customer already runs, woven into the live call instead of bolted on beside it.

See how it fits BLADE on GitHub

JSR-359 SIP Servlet Oracle OCCAS 8.0 – 8.3 1000+ CPS per node

BLADE The call on OCCAS Speech & AI Identity & fraud CRM & screen-pop Recording Analytics Media server
34

Shipped artifacts across 130 unique packages — every WAR, EAR and JAR audited package by package.

15+

Production SIP services out of the box: registrar, proxy, balancer, transfer, hold, queue, presence, analytics, access control.

12

Browser-based admin tools, deployed as one EAR in one step. No SSH session required.

~12 lines

A custom enterprise routing application: subclass the framework's iRouter base, override two factory methods, done.

Why Vorpal exists

The features OCCAS doesn't have, added without leaving it

OCCAS decides the call. A contact center needs a great deal that OCCAS was never meant to do. BLADE makes OCCAS an integration point: reach into the systems the customer already runs, chain in another vendor's application, or plug in a capability the stack lacks, all woven into the live call rather than bolted on beside it.

Reach into the systems already running

REST, LDAP and database connectors, circuit-broken so a slow backend never drags the call into a timeout. Look up the caller, score the risk, pull the account, mid-call.

Chain in another application

The application router branches on anything in the message and hands the call to another SIP application, yours or a third party's, then takes it back. Build one service out of many parts.

Bring your own media

The media layer is the Java standard, JSR-309, so any compliant media server plugs into the call the same way. Gryphon is ours; a customer is never locked to it.

What gets integrated is whatever the contact center already runs: speech, transcription and translation; identity, verification and fraud scoring; CRM lookups and agent screen-pop; recording, archival and compliance; analytics and workforce systems; chatbots and self-service front doors. The customer chooses the vendor. BLADE brings it into the live call.

What ships

A framework, a router, and the services you were going to write anyway

BLADE is not a stack you assemble. Every module below builds from one Maven reactor and deploys into an existing OCCAS domain.

The core idea under all of it: a whole call is one readable, top-to-bottom method, not logic scattered across a dozen handlers. That is also why dropping in a third party is cheap. You add it to the flow, not to a maze.

Before · a call across scattered handlers

B2buaServlet.java JSR-359 
public class B2buaServlet extends SipServlet {

  protected void doInvite(SipServletRequest alice) {
    SipSession bob = linkNewSession(alice);
    alice.getSession().setAttribute("peer", bob);
    bob.setAttribute("alice", alice);      // breadcrumb
    createOutbound(bob, alice).send();
  }

  protected void doSuccessResponse(SipServletResponse res) {
    SipSession bob = res.getSession();
    SipServletRequest alice =
        (SipServletRequest) bob.getAttribute("alice");
    bob.setAttribute("bobResponse", res);  // breadcrumb
    alice.createResponse(res.getStatus()).send();
  }

  protected void doAck(SipServletRequest ack) {
    SipSession bob =
        (SipSession) ack.getSession().getAttribute("peer");
    SipServletResponse res =
        (SipServletResponse) bob.getAttribute("bobResponse");
    res.createAck().send();               // breadcrumb
  }

  // ...plus doBye(), doCancel(), doErrorResponse(),
  // doProvisionalResponse(). Every attribute saved
  // and restored by hand, in order.
}

After · one BLADE callflow, anything drops in

B2buaCallflow.java BLADE 
public class B2buaCallflow extends Callflow {

  public void process(SipServletRequest aliceRequest) {

    SipServletRequest bobRequest =
        createRequest(aliceRequest);

    sendRequest(bobRequest, (bobResponse) -> {

      SipServletResponse aliceResponse =
          createResponse(aliceRequest, bobResponse);

      sendResponse(aliceResponse, (aliceAck) -> {
        SipServletRequest bobAck =
            createAcknowledgement(bobResponse, aliceAck);
        sendAcknowledgement(bobAck, bobResponse);
      });

    });
  }
}

// The call is a straight line. Slot a lookup, a
// vendor, or a media step in wherever you need it.

Lambda callflows

Express entire SIP conversations as readable, top-to-bottom code. B2BUA, proxy and transfer patterns ship ready to extend.

JSON-driven configuration

Dynamic config with JSON Schema validation and hot reload over JMX. No restart to change behavior.

SIP-aware logging

Structured logs that render sequence diagrams, with per-application log files and ANSI color in the terminal.

SDP model

A real parse/serialize SDP object model, plus RFC 3264 hold, mute and resume in framework.v3.media.

Circuit-broken lookups

REST, LDAP and JDBC enrichment with breakers, so a flaky backend stops dragging calls through timeouts.

Analytics

Call detail records and multi-tenant analytics — one database serving many customers, each seeing only its own calls.

Operations

Operate it from a browser, not an SSH session

Twelve admin applications deploy to the WebLogic AdminServer behind a single portal and a single login. Every one of them is a skinny WAR — no third-party JAR ships inside it.

/blade/configurator

Configurator

Every service's configuration edited through forms generated live from its JSON Schema — version history, validation, guided dropdowns for known keys, one-click publish to the running cluster. No restarts.

/blade/flow

Flow

Draw the FSMAR routing plan as a diagram, run the route simulator against it, replay a real call, and watch a live heat overlay of production traffic. Exports real SVG and a printable routing plan.

/blade/tuning

Tuning

OCCAS, WebLogic and JVM tuning with one-click Recommended presets encoding high-CPS heuristics, a read-only Health Check that flags latency-killing misconfigurations, and JDK 21 low-pause GC set up correctly.

/blade/callflow

Trace

Follow a single call through every application that touched it, rendered as a sequence diagram rather than a haystack of log lines.

/blade/logs

Logs

Tail every node in the cluster from one page, with per-server minimum severity set from the Tuning app.

/blade/api

API Explorer

Live-discovered, deep-linkable OpenAPI documentation for every running service, alongside a browsable Javadoc site with generated UML class diagrams.

Also in the portal: CRUD editor, file management with versioned backups, analytics administration with one-click JMS provisioning, and printable reports from the Tuning, Balancer, Trace, iRouter and Flow apps.

Carrier-grade

Built for the night the backend goes down

BLADE runs in clustered, 1000+ CPS deployments where every node operates independently. There are no singletons and no single point of failure — by design, not by configuration.

  • Graceful overload drain. When an engine is overloaded it tells the load balancer to stop sending new calls; in-flight calls finish undisturbed.
  • Circuit breakers on REST, LDAP and database lookups — and the NOC gets exactly one SNMP trap down and one up per outage, not a trap storm.
  • NMS-ready monitoring using the standard MIB your operations team already has.
  • Predictable, bounded pause times from a low-pause GC configuration the Tuning app sets up for you.
  • State that survives the node. Callflow and routing state both serialize, so a failed engine costs you nothing visible.
overload → drain → recover Behavior 
// 1. Engine crosses its load threshold.
engine.load        > threshold

// 2. BLADE signals the balancer — new calls stop.
OPTIONS → 503 Service Unavailable
Retry-After: 0

// 3. Calls already up are never touched.
inFlight           → continue to completion

// 4. Load falls; the engine advertises itself again.
OPTIONS → 200 OK

// One SNMP trap down. One up. Nothing in between.

Security

Scan-clean by design, not by patch

The entire dependency tree was audited package by package. Legacy libraries were removed outright rather than patched around.

One place to patch

Application WARs carry only BLADE code. Every third-party library lives in one centrally-managed shared library, so a single bump patches the whole fleet at once.

Minimal attack surface

Sites with strict scanning policies can run headless: config auto-publish with no UI, no servlets, no login page. Nothing to probe.

Locked down by default

Changes go live only by explicit operator action. File editing is deny-by-default whitelist with path-traversal guards and automatic versioned backups.

Exact-origin CORS

Allowlist only — wildcards are intentionally unsupported. Not a setting you can get wrong in a hurry.

Credentials can't leak

Four independent safeguards stop a password being committed by accident. Environment configuration files never ship in the repository.

Air-gap friendly

Zero CDN dependencies anywhere in the admin tier. Everything an operator loads is served by your own domain.

Zero known vulnerabilities across all 34 shipped artifacts and 130 unique packages, verified against CVE databases current as of the dependency audit. Rescan before you rely on it — see SECURITY.md.

Deployment

Four tiers, one command

One environment file is the single source of truth — admin URL, per-tier WebLogic targets, engine node list, application allowlist. Then ./deploy.sh <env> does the whole domain in dependency-safe order.

1

Shared library

blade-shared — every third-party JAR, deployed once to both the AdminServer and the cluster.

2

Application router

The FSMAR fat JAR, dropped into the OCCAS approuter/ directory. Engine-tier restart.

3

Admin applications

Skinny WARs to the AdminServer, behind one portal and one login page.

4

Services

Individual service WARs to the OCCAS cluster — the engine tier that actually handles calls.

build & deploy 
# One-time: install the OCCAS JARs from $MW_HOME
$ ./bootstrap.sh

# Build. Platform is detected from $MW_HOME.
$ ./build.sh production

# Sanity-check the whole environment first
$ ./deploy.sh production --dry-run

# shared → fsmar → admin → services, in order
$ ./deploy.sh production

# ...or just one tier
$ ./deploy.sh production services

Targets OCCAS 8.0 through 8.3 (JDK 8, 11, 17 and 21). Switch platforms by re-pointing $MW_HOME — no edits to build configuration.

In production

Thirteen years in the making

  • SCALE Tested against the largest healthcare call center in North America.
  • CRITICAL 911 traffic from a nationwide satellite-radio provider passes through BLADE.
  • CARRIER Going into deployment at a top-three global carrier.
  • SUPPORT Backed by a 300-consultant systems integrator and an enterprise platform sales organization.

Customer names are withheld by agreement. Prospective customers: we will put you on a call with a working architect who runs it.

One example, ours · built on BLADE

Gryphon

Our own plug-in: in-network media and voice AI

Gryphon is the plug-in Vorpal built through the same JSR-309 seam any vendor uses: an in-network media server with voice AI, on the OCI Arm hardware the calls already run on, with the audio never leaving the network. It is one example of what fits into the Oracle stack, and a customer is never locked to it.

50

Concurrent media streams per node, zero RTP loss, first audio under 60 ms. Anchor, play, record, DTMF and N-party mix, standards-compliant JSR-309.

195 ms

To rehome a live call when a media server dies: callers lose about 20 ms of sound. Control-plane loss reattaches in ~150 ms with no gap at all.

9.55%

Equal-error rate of the in-network deepfake detector, scored inline on 100% of calls on Arm cores, measured on the In-the-Wild corpus at the telephony band.

0 GPUs

The voice models are int8 on Ampere Arm cores, the same silicon the media server runs on. No NVIDIA fleet, and the audio never leaves the network.

Your audio never leaves the network

Every cloud voice-AI ships call audio to an API. Gryphon runs the models on the box the call already flows through. For healthcare, finance and government that is a procurement gate, not a feature.

It can act on the call

Because BLADE owns the SIP leg, Gryphon can transfer, whisper, barge, mute or conference-in mid-call, on a spoken command or a risk score. Cloud AI listens beside the call. Gryphon is in it.

No GPU fleet

Audio is integer math, and so is quantized inference. The models run int8 on Ampere Arm cores, the same silicon the media server uses. The part that sounds exotic is the part that makes it cheap.

On-net agents

Several tiny agents share one call

The models are small enough to stack. On one live call the ears transcribe while the caller is still talking, four attendants share the floor each in its own voice, and the scam detector scores the audio every second. The model is the mouth and the ears, never the brain: a deterministic layer keeps deciding.

  • Small enough to stack: several agents on one call, and 128 conversations on a single node.
  • Live on real PSTN calls since August, floor-arbitrated so agents take turns and yield when you talk over them.
  • All on Arm CPU cores. No GPU anywhere, and the audio never leaves the node.
one call · concurrent agents Behavior 
// On one live call, at once:
ears (ASR)     → int8 · ~7 streams / core
understanding  → 0.5B · int4 · 4 cores · ~250 ms
intent         → 23 MB embedding · ~10 ms
voice (TTS)    → live · ~100 ms / sentence
scam score     → 1.6 MB int8

// Four attendants share the floor. A node holds 128.

Headline proof point

A scam detector that lives where the call flows

The synthetic-voice detector is not a cloud call-out. It is a 1.6 MB int8 model scoring the caller's audio in-process, on every call, on the media box's own Arm cores. It costs about 3% of one core per call. When a score crosses the line, the application already owns the SIP leg, so it can whisper the agent, barge, or drop.

  • 9.55% EER on In-the-Wild at the telephony band, 0.11 points off a teacher model 200 times its size.
  • Inline on 100% of calls as Tier 1; a heavier model (7.19% EER) confirms only the calls Tier 1 flags.
  • A signal, not a verdict. Gryphon fuses it with signaling and provenance; your application decides.
in-call risk scoring Behavior 
// Tier 1: inline, every call, on the media box.
w2mid.int8.onnx     → 1.55M params · 1.6 MB int8
In-the-Wild EER     → 9.55%  (8 kHz telephony)
cost                → ~3% of one core / call

// A risk score is a signal. The app owns the call.
score > threshold  → whisper · barge · transfer · drop

// Tier 2: heavier model, only on flagged calls.
In-the-Wild EER     → 7.19%

Every number here was measured on Vorpal's own OCI Arm rig, none projected, and the detector runs in the call path today. It is live in Ashburn. Call it.

On the roadmap

What the callflow model unlocks next

The same properties that make callflows readable — straight-line code, state that serializes itself, a router that can branch on anything in the message — make the next generation of call handling tractable.

Verified and branded calling

STIR/SHAKEN attestation and Rich Call Data. Verify on inbound INVITE and surface the verified name and logo into the callflow as session attributes any downstream application can read; sign and attach per-call RCD on outbound. Sign-on-INVITE is a callflow, which is exactly why this is straightforward here and static everywhere else.

More in-network intelligence

The same media tap that carries the scam detector carries the next models: live translation and captioning, sentiment and escalation, compliance keyword monitoring. Each rides the pipeline Gryphon already runs, scored on the box, the audio still never leaving.

Read the code. It's the whole pitch.

BLADE is MIT licensed and public. Clone it, point $MW_HOME at your OCCAS install, and have a callflow running this afternoon.

github.com/vorpalnet/blade Browse the API Talk to us