AI-driven voice needs primitives that cloud platforms do not own: event-driven routing, stateful in-flight handling, media and SIP coordination, resilient failover, and a signaling path inside the operator network rather than a SIP trunk beside it. OVOO Trinity is three parts working on the same call.
OVOO JSLEE holds signaling and session state in real time. The OVOO media layer handles the audio, with native real-time speech recognition and synthesis. OVOO Cortex is the decision layer that reasons about what should happen. The network stays under deterministic operator control, and the AI layer gets a defined place to decide inside it.
Captures every event from the network, hands the decision point to Cortex, and executes the answer immediately: connect, hold, reject, verify, redirect.
Session state, activity contexts, timers, clustering and failover stay here, in the layer that already understands their lifecycle.
This is the same runtime that is in production carrying revenue-affecting traffic.
The media server.
Audio stream handling with real-time speech-to-text and text-to-speech integrated natively rather than bolted on through a third-party hop.
This is what lets the network speak to a caller and understand the answer inside the same call.
The decision layer.
An agent with memory that holds conversation context and learns subscriber behaviour, speaks MCP, and reaches external systems such as a calendar or a CRM over a controlled path, to act on the subscriber's behalf.
It decides; it does not touch signaling directly.
Three layers on one live call, all of them inside the operator network
The split is the point. Probabilistic reasoning stays out of protocol state, while operations teams keep one clear place to enforce policy, latency budgets and fallback.
Cloud voice-AI platforms compete on application-layer speed and developer experience, and they are good at it.
What none of them owns is carrier-grade control of signaling and media. Reaching an operator network means a SIP trunk and a hand-off.
OVOO Trinity sits on the other side of that hand-off, as the real-time layer an operator already trusts with revenue-affecting traffic.
The live-conversation loop has one end-to-end budget for recognition, reasoning and speech.
That budget is protected when the layer holding session state and media stays inside the operator network rather than adding network round trips.
Every external hop spends from the same budget.
A trusted business contact calls.
JSLEE identifies the call and holds it.
Cortex checks your calendar, sees you are in a meeting and finds the next free slot.
The OVOO media layer tells the caller: "Greg is busy right now. I can see he is free at 14:00. Shall I book it?"
The caller says yes and Cortex writes the meeting.
Normal call handling, exactly as today.
An unknown number calls.
JSLEE holds the call while the OVOO media layer asks what it is about and transcribes the answer in real time.
Cortex reads the intent.
Telemarketing is rejected before it ever reaches you.
A genuine call is forwarded with context attached, and you decide whether to pick up.
The call rings as it does today.
Instead of sending the caller to voicemail nobody listens to, the network manages your time.
A scoring decision inside call setup, against a policy threshold the operator sets, on a signaling path we already control.
Fallback: the deterministic rule set already running in the service.
AI-selected in-call content delivered over an operator-controlled signaling and media path rather than through an app the callee has to install.
Fallback: standard call presentation.
A recommendation taken inside a live charging session, bounded by policy, with a latency budget.
Fallback: the tariff rule as configured.
OVOO JSLEE runs on the Apache Pekko actor model: streams with backpressure and non-blocking pipelines instead of blocking I/O inside a monolith, and sharded actors for horizontal scaling on Kubernetes.
The same property that makes it scale is what makes an agent per subscriber a natural unit rather than an add-on.
An actor is long-lived and stateful by construction, so a subscriber's agent can hold context across calls, not only within one session.
Long-lived stateful actors, so context survives beyond a single session
Streams with backpressure, so a slow decision service degrades instead of collapsing
Sharded actors, so scaling is horizontal rather than vertical
Event handler budgets stay in the signaling layer
Legacy JAIN SLEE containers were not built around this. One runs blocking I/O inside a JBoss monolith; the other carries cluster-singleton bottlenecks. Both can route a call. Neither gives you a stateful agent per subscriber without building an event and state engine alongside it.
Activity contexts, timers, dialogs and protocol state remain in the runtime that understands their lifecycle. The decision layer reads and recommends; it does not hold the call.
Timeouts, confidence thresholds, allowlists, permitted action sets and human-approved rules determine whether a recommendation can affect a live service at all.
Every integration defines what happens when the decision service is slow, unavailable or below the accepted confidence threshold. Model latency does not become a signaling outage.
Correlation identifiers, metrics, traces and decision records connect each request to the resulting telecom action, so operations can reconstruct what happened and why.
OVOO is building this pattern for a Tier-1 European operator today.
JSLEE carries the carrier-grade signaling and media, and a decision layer above it drives the in-call experience.
The substrate is the same runtime that is in production.
OVOO provides the substrate and the engineering. The model, the data boundary and the production controls are scoped for each use case.
Three products working on the same live call.
OVOO JSLEE holds real-time signaling, session state, failover and policy under carrier-grade control.
The OVOO media layer handles the media, with native real-time speech recognition and synthesis.
OVOO Cortex is the decision layer that reasons about the call and can act on the subscriber's behalf through controlled access to external systems.
Trinity is a platform and an engineering capability, not a shrink-wrapped consumer app. The signaling runtime is in production today. The service, the model and the integration scope are defined per use case.
No. Protocol and session execution stay in OVOO JSLEE. A decision passes through operator-defined policy, validation, timeout and fallback controls before it can influence a live service.
Each integration defines a time budget, a deterministic fallback, a retry or bypass policy, and an explicit rule for behaviour below an accepted confidence threshold. The call completes on the fallback path.
SIP and IMS-related service logic, SS7 with CAP and INAP, SMPP, HTTP and REST, and database integrations. Diameter is available through an OVOO adaptor, with the exact application interfaces confirmed during scoping.
Yes, subject to review. The SBB, resource adaptor, profile, activity and timer model stays the anchor. AI-assisted decisions are introduced to selected services in stages rather than through a platform-wide rewrite.
Because of the latency budget and the state. Recognition, reasoning and speech have to complete within the live conversation loop, and every hop outside the network spends part of that budget. Session state, timers and failover also have to survive a node loss mid-call. OVOO JSLEE runs on the Apache Pekko actor model, which keeps event handling in the signaling layer and makes a long-lived per-subscriber agent workable.
Trinity assumes a maintained runtime underneath it. If you are still on Mobicents, RestComm or Rhino, start with the migration: same service model, current Java LTS, staged per service with rollback.
