Programmable IMS: Service Profiles That Turn Voice Into a Platform

Voice Networks Have a Flexibility Problem

Modern telecom demands more than dial tone. Operators need to launch new services quickly, integrate third-party applications, differentiate per customer segment, and prepare for AI-driven capabilities – all without ripping out their core network every time something changes.

Yet most IMS deployments remain monolithic. The S-CSCF handles signaling and service logic. Adding a new application server means a vendor engagement. Customizing behavior for a single subscriber means editing global configuration. And replacing one component means replacing everything.

That model served its purpose. It no longer does.

The Architecture Shift: Separate Signaling from Services

At volte.io, we built our IMS core around a principle that 3GPP defined years ago but few implementations follow cleanly: decouple the signaling plane from the service layer.

In practice, this means:

The S-CSCF does not need to know what a service does. It only needs to know when to invoke it. That decision is driven entirely by Service Profiles.

Service Profiles: The Control Plane for Services

A Service Profile, stored in the HSS, contains a set of Initial Filter Criteria (iFC) that tell the S-CSCF exactly which Application Servers to invoke, in which order, and under which conditions. This is defined in 3GPP TS 29.228 and TS 29.229.

Think of it as a programmable routing table for voice services. Instead of hard-coding service logic into the call processing engine, operators describe what should happen declaratively – and the network executes it.

Different subscribers can have different profiles. Premium customers get AI-assisted call handling. Enterprise users get compliance recording. Default subscribers get standard telephony. All configured in the HSS, all executed through the same signaling path.

What We Built on Top

To fully leverage Service Profiles as a platform capability, we introduced purpose-built components that plug directly into this architecture:

Each of these runs as an independent, horizontally scalable service. They are invoked through iFC, communicate via standard SIP, and can be deployed, updated, or replaced without touching the core signaling layer.

How a Call Actually Flows

When a subscriber initiates a call, the signaling path is clean and deterministic:

1. UE sends INVITE – the call enters the network through the P-CSCF
2. S-CSCF retrieves the Service Profile from the HSS for this subscriber
3. iFC rules are evaluated – matching criteria determine which Application Servers to invoke
4. Application Servers execute service logic – MMTel applies forwarding rules, the MRF plays an announcement, or an AI engine processes the call
5. Call continues to the terminating side through the S-CSCF

Every step follows 3GPP standards. Every Application Server is replaceable. Every subscriber can have a different path through the service chain.

Shared iFC Sets: Scale Without Complexity

Managing individual filter criteria per subscriber does not scale to millions of users. That is why we support Shared iFC Sets – group-based service definitions that can be assigned to entire customer segments at once.

• Define a service bundle once, assign it to thousands of subscribers instantly
• Update centrally – a single change propagates across every subscriber in the group
• Combine with per-subscriber overrides for fine-grained control where needed

This means operators can roll out a new service tier, activate AI features for a customer segment, or launch a promotional offering – all without per-subscriber configuration and without core network changes.

True Multi-Vendor: Mix & Match Without Compromise

Because the service layer communicates through standard SIP interfaces and iFC-based invocation, the choice of Application Server vendor is completely independent from the choice of IMS core vendor.

This is not theoretical. In practice, it means:

• Use volte.io MMTel alongside a third-party conferencing server from a specialist vendor
• Integrate an external AI voice processing engine for real-time transcription or language translation
• Add fraud detection, analytics, or compliance recording from best-of-breed providers
• Replace any single component without touching the rest of the network

AI-Ready from Day One

Service Profiles make AI integration a configuration task, not an engineering project. Because iFC can route traffic based on subscriber identity, service tier, or call characteristics, operators can selectively direct calls through AI-powered Application Servers without changing the core network.

The key insight: AI services are just another Application Server in the chain. They follow the same invocation model, the same SIP interfaces, and the same per-subscriber configurability. No special integration. No platform lock-in.

The Business Case

A programmable IMS core is not just an engineering achievement. It directly changes the economics and agility of voice services:

Conclusion

The IMS core does not have to be a rigid, single-vendor black box. With 3GPP Service Profiles at the center of the architecture, it becomes what it should have been all along: a programmable service platform for voice.

At volte.io, this is not a roadmap item. It is how the platform works today:

• Clean separation of signaling and service logic
• Multi-vendor flexibility through standard SIP + iFC interfaces
• Per-subscriber intelligence driven by Service Profiles in the HSS
• AI-ready service chaining without core network modifications