OVOO JSLEE

The maintained JAIN SLEE runtime for services you cannot rewrite

If your telecom services run on Mobicents, RestComm or Rhino, the service model is not your problem. The runtime under it is. OVOO JSLEE implements the JAIN SLEE 1.1 service model defined by JSR-240, so your existing SBBs, resource adaptors, profiles, activities and timers keep running while the runtime, the Java version and the operations model change underneath them.

It is built on the Apache Pekko actor model, which is why the same runtime that scales horizontally on Kubernetes can also hold a stateful agent per subscriber. OVOO JSLEE is in production at a Tier-1 European operator, with an active Mobicents-to-OVOO JSLEE migration engagement.

Talk to an engineer See how the migration runs

JAIN SLEE 1.1 (JSR-240)Java 21 LTSApache Pekko actor modelPer-service rollbackKubernetes-nativeCommercial licence

Where your platform actually stands

The service model is fine. Everything around it stopped moving.

Three different situations bring operators to this page. Find yours.

If you run Mobicents or RestComm

Open the public repository and look at the release history. It carries 823 tags and no published releases.

Every branch still in it was last touched in 2018. The automated build tags stop in November 2020. The only change since then is an edit to the README in January 2024.

Commercial support for the on-premise JSLEE moved to a third company in 2023, the third owner in that lineage.

The application logic your team wrote is still good. Nothing in that repository is going to patch the platform it runs on.

If you licence Rhino

Technically this is the shorter migration. The service model is close to ours, so the friction is mainly management API and resource adaptor configuration rather than application logic.

The harder question is not technical. Rhino has changed hands several times over the past decade, the release cadence is set by the vendor rather than by you, and every renewal is a decision made against a roadmap you do not control.

Worth knowing what the alternative looks like before the next renewal date.

If your container is licensed AGPL

The community JAIN SLEE container is licensed under AGPL-3.0, and so are the newer open-source forks of it.

If your team extended the container and you operate it as a network service, your own service logic sits inside that licensing conversation.

That logic is usually the part you would least like to publish. OVOO JSLEE is licensed commercially, with no copyleft reach into your code.

This usually becomes urgent when:

A security audit raises a finding against the platform.
A Kubernetes programme reaches the one workload that will not containerise cleanly.
An internal mandate retires an unsupported JVM.
A licence renewal date arrives.
Legal reviews the AGPL exposure on a service you built in-house.
A NIS2 obligation requires documented patching, dependency visibility and incident handling that the current platform cannot evidence.

What actually moves

Your service model is the migration anchor, not the obstacle

OVOO JSLEE implements the JAIN SLEE 1.1 service model defined by JSR-240. SBBs, resource adaptors, profiles, activity contexts and timers keep the meaning they already have in your services, which is what makes a staged migration possible at all.

A compatibility layer maps the parts that are specific to your current runtime: Mobicents extensions such as Tracer, MobicentsCluster, Activity Context property tables, XStream marshallers and JBoss JNDI, and on the Rhino side the management APIs and adaptor configuration.

One service at a time, in a sequence you choose
Compatibility shims built only where the evidence requires them
Behaviour compared against the current system before anything moves
Rollback criteria written down before each step

The result is that existing SBB and RA code runs while the runtime, the Java version and the deployment model change around it.

OVOO JSLEE between telecom protocol domains, with Apache Pekko as the runtime model

Apache Pekko actor model · HA clustering

The other option on the table

Rewriting looks modern and prices worst

For engineering

Your SS7, MAP, CAP, INAP, Diameter and SIP logic encodes years of solved edge cases: timer tuning, retransmission handling and error recovery hardened against real interconnect. A rewrite re-opens every one of them.

REST is stateless, while telco signaling is stateful and timing-critical. JAIN SLEE gives you long-lived activity contexts and in-flight state recovery when a node is lost.

Rebuild that on microservices and you end up re-implementing an event and state engine equivalent to SLEE, without the specification and without the battle testing.

JSR-240 has been stable since 2008. The specification was never the problem. The runtime was.

For procurement and risk

A rewrite is a multi-year programme with a single cutover, full re-certification and regression against live interconnect, a parallel-run period, and a team that has to hold two systems in its head at once.

It also re-opens revenue-affecting validation, including charging accuracy, where an error costs money directly.

A layered migration keeps the proven code, moves one service at a time and keeps a return path at every step.

Comparing what you run with what you need

Product names do not determine migration effort.Versions, custom code and adaptors do.

Decision area	Mobicents / RestComm	Rhino	OVOO JSLEE
Public maintenance	823 tags, no published releases; all branches last touched 2018; build tags stop November 2020; README edited January 2024	Not open source; releases follow the vendor's cadence	Actively maintained product with a current roadmap
Who is accountable	Commercial support for the on-premise JSLEE moved to a third company in 2023	The vendor, under your licence terms	OVOO: we build it, maintain it and support it
Licence	AGPL-3.0, including the newer open-source forks	Commercial, vendor terms	Commercial, with no copyleft reach into your service logic
Execution model	Blocking I/O inside a JBoss monolith	Traditional container with cluster-singleton bottlenecks	Apache Pekko actor model, streams with backpressure, sharded actors
Deployment	Single JVM per node, static VM or bare-metal sizing; boot time does not fit Kubernetes liveness and readiness probes	Vendor-supplied container images	OCI containers, Helm, Terraform, GitOps, blue-green with rollback on SLO regression
Migration friction to OVOO JSLEE	Vendor extensions: Tracer, MobicentsCluster, Activity Context property tables, XStream, JBoss JNDI	Management API and resource adaptor configuration mapping	Target platform
First step	Compatibility review against the build you actually run	Compatibility review against the release you licence	Fixed-price review, a few days

What you are migrating onto

A current runtime around a service model that already works

JSR-240 service model

Your SBBs, resource adaptors, profiles, activity contexts and timers keep their meaning. The service model is the anchor, so the runtime can change without an application rewrite.

Apache Pekko actor model

Event handling runs on actors and streams with backpressure instead of blocking I/O inside a monolith. Sharded actors give horizontal scaling on Kubernetes, and they are also what makes a long-lived stateful agent per subscriber a natural unit rather than a bolt-on.

Protocol adaptors

SIP, SS7 with CAP and INAP, SMPP, HTTP and REST, and database adaptors. Diameter is available through an OVOO adaptor based on RFC 6733, with application-specific interfaces confirmed during scoping.

Java 21 LTS

Use a long-term-support release that fits a predictable support policy and upgrade cadence. Java 21 LTS is actively patched.

Continuity by design

Clustering, health checks, session recovery and graceful degradation, so a staged transition and normal operation use the same mechanisms.

Observability built in

Tracing, metrics and service-level indicators, so runtime behaviour is visible before, during and after a cutover rather than only afterwards.

Four stages

Four stages, and you can stop after any of them

The first commitment is a fixed-price report that takes days, not months. Nothing is irreversible until you switch the old system off.

Compatibility review

Fixed price, a few days. We go through what you run today: SBBs, resource adaptors, descriptors, configuration and protocol dependencies.

You get a written report that separates what runs unchanged, what needs a compatibility shim and what needs rework, with effort per service and a recommended first service to move.

Your decision: Is there a case. Nothing in production has been touched.

One service, proven in lab

We deploy that first service on OVOO JSLEE in your lab environment, and you run your own functional and load tests against it.

Behaviour, latency, state handling and error paths are compared with the current system against thresholds you set. Where your environment supports traffic mirroring we use it, but it is not a prerequisite.

Your decision: Does it pass your own acceptance tests. Still nothing in production.

Service-by-service cutover

Services move one at a time against acceptance criteria you approved, each with canary or blue-green rollout, a rollback procedure and an operator runbook.

There is no single switch-over date, and no point at which both systems are unavailable.

Your decision: Taken per service, and reversible until you switch the old system off.

Ownership

Documentation, training and handover to your team, or OVOO operates it. Your call, and it does not have to be made at the start.

Your decision: Who runs it.

Nothing in production is touched

Your acceptance tests decide

Production starts here

You decide who owns it

For engineeringWhat happens inside each stage

Compatibility report

Record the exact runtime and build, Java distribution, SBBs, resource adaptors, profiles, timers, descriptors, protocol dependencies and operational integrations.

Friction matrix

Separate standard JSR-240 behaviour from vendor extensions, custom management APIs, non-standard descriptors and adaptor-specific configuration.

Target architecture

Define the Java 21 LTS runtime, containers, Kubernetes, observability, resilience and security controls around it.

Shim set

Create only the converters, adaptor shims and targeted code changes the evidence requires, without rewriting proven application logic.

First migrated service

Select a representative first service, deploy it on OVOO JSLEE and validate descriptors, state, timers, protocol handling and operational behaviour.

Test results

Mirror or replay traffic and compare outcomes, latency, errors and state handling against agreed service-level guardrails.

Cutover record

Use canary or blue-green rollout, explicit rollback criteria and an operator runbook instead of a single irreversible switch.

Handover pack

Apply the proven path service by service, refine automation and complete operating documentation, training and ownership transfer.

Security and resilience

Built to pass the audit you are going to have

Each of the six NIST CSF 2.0 functions maps to a named platform capability and a named operational process, documented per function: Govern, Identify, Protect, Detect, Respond, Recover.

Supported Java LTS with active patching.
A dependency inventory and an SBOM per release.
Vulnerability handling with a defined disclosure and patch path.
Telemetry and alerting wired to runbooks rather than to a dashboard nobody owns.
Tested rollback and recovery procedures.
Reporting evidence that fits the NIS2 24-hour preliminary and 72-hour detailed notification windows.

NIS2 obligations sit with your organisation, not with a supplier. What we provide is the evidence for the technical measures under Article 21, in the form your auditor asks for it.

A platform with no published releases and no accountable owner cannot show you a patch process, a dependency inventory or a vulnerability handling path. That is what an auditor asks for first.

Govern

Clear service ownership, change control and management oversight.

Identify

A current inventory of services, adaptors, dependencies, suppliers and the exact JDK distribution.

Protect

Supported Java releases, patch processes, least privilege, secrets management, encryption and hardening.

Detect

Telemetry, anomaly detection and alerts connected to operational runbooks.

Respond

Containment and communication playbooks supported by usable runtime evidence.

Recover

Backups, tested rollback, disaster recovery and continuity procedures.

Production evidence

OVOO JSLEE is in production at a Tier-1 European operator with an active Mobicents-to-OVOO JSLEE migration engagement.

Talk to an engineer

Start here

Compatibility review

Service, adaptor and dependency report. Friction and risk matrix. Staged plan with a first-service candidate.

Discuss the review →

Build the bridge

Migration foundation

Target runtime and operating model. Shims and the first service migrated. Automated test and observability foundation.

Scope the foundation →

Move safely

Production transition

Canary or blue-green rollout. SLO guardrails, rollback and operator runbooks. Handover or managed engineering support.

Plan the transition →

FAQ

What migration teams usually ask first

Is JAIN SLEE obsolete?

Not as a service model. JAIN SLEE 1.1 is defined by JSR-240 and has been stable since 2008. It remains a good fit for event-driven telecom services. The real question is whether the runtime you operate can meet your current Java, security, support and deployment requirements.

Is the open-source JAIN SLEE container still maintained?

Look at the repository. It carries 823 tags and no published releases. Every branch still in it was last touched in 2018, the automated build tags stop in November 2020, and the only change since is a README edit in January 2024. Commercial support for the on-premise product moved to a third company in 2023. There are newer open-source forks, including one published in February 2026 that moves the compile target to Java 11, with three commits and no releases at the time of writing.

What licence is it under, and why does that matter?

The community container is AGPL-3.0, and so are the newer forks. If you extended the container and you run it as a network service, your own service logic is part of that licensing question. OVOO JSLEE is licensed commercially, with no copyleft reach into your code. Your legal team will want to look at this before your engineers do.

Do we have to rewrite our SBBs and resource adaptors?

The migration is designed to preserve the SBB, RA, profile, activity and timer model. How much reuse you get depends on your descriptors, vendor extensions, management integrations and custom adaptors, so we confirm compatibility service by service rather than promising it up front.

Does this require new CAPEX or a risky application rewrite?

The model is designed to maintain business continuity without a rewrite: proven service logic is preserved and change is staged per service. Project-specific infrastructure and integration scope is confirmed in the compatibility review before any work begins.

How does a Mobicents or RestComm migration start?

With the exact version and build you operate, then an inventory of SBBs, resource adaptors, descriptors, Java dependencies and runtime-specific extensions. That evidence picks the first service, defines any shim we need, and sets the tests it has to pass in your lab.

How does a Rhino migration start?

The same evidence-first approach. We map the service model, deployment descriptors, management dependencies and adaptor behaviour. The output is a compatibility matrix and a staged plan, not a blanket promise of binary compatibility.

What Java version does OVOO JSLEE run on?

Java 21 LTS. It provides a long-term-support release for a predictable support policy and upgrade cadence.

Does NIS2 prohibit a particular Java version or open-source software?

No. NIS2 names no language, product or version. Article 21 requires risk-management measures, including security in acquisition, development and maintenance, and vulnerability handling. A maintained Java 11 distribution still receives security updates. The practical risk is not a version number: it is a platform with no support path, no dependency visibility and no accountable vulnerability management, which is what an auditor will ask you to evidence.

How does OVOO describe JAIN SLEE compatibility?

OVOO JSLEE implements the JAIN SLEE 1.1 service model defined by JSR-240. Service, adaptor and runtime-extension compatibility is confirmed against what you actually run, during the compatibility review.

Which telecom protocols are supported?

SIP, SS7 with CAP and INAP, SMPP, HTTP and REST, and database adaptors. Diameter is available through an OVOO adaptor based on RFC 6733, with application-specific extensions confirmed during scoping.

How do you reduce cutover risk?

The first service is proven in your lab against your own tests before anything moves. Production then changes one service at a time, using canary or blue-green rollout, service-level guardrails, written rollback criteria and an operator runbook, rather than a single irreversible switch.

A separate track

The same runtime is the layer under AI-driven calls

This page is about replacing a runtime safely. OVOO Trinity is a different conversation: how a carrier-grade real-time layer, a media server and an AI decision layer work together on a live call, with the network staying under operator control.

Explore OVOO Trinity