What Is IMS? IP Multimedia Subsystem Architecture Explained for Voice Engineers

You meet IMS the moment a VoLTE call lands on your interconnect, a mobile operator asks you to peer with their core, or an RCS message needs somewhere to terminate. The acronym shows up in spec sheets, peering agreements, and trouble tickets, usually without anyone stopping to define it. In telecom, IMS means the IP Multimedia Subsystem, the standardized IP core that carries voice, video, and messaging over a single packet network.

In this article, we’ll walk you through what IMS is, the functional elements that make up the IMS core, how a session moves through it, and where the Session Border Controller (SBC) sits at its edges. If you operate SIP interconnects or evaluate SBCs, this is the layer that explains why so much carrier traffic eventually arrives at your border. TelcoBridges has spent more than twenty years working at exactly that boundary between legacy TDM signaling and modern IP.

What IMS Means (and What It Does Not)

IMS stands for IP Multimedia Subsystem, an architecture standardized by 3GPP in TS 23.228. It is a framework, not a single product or box. Operators buy IMS implementations from vendors, and each vendor maps the standardized functions onto their own software, but the reference architecture and the interfaces between functions stay consistent across deployments. That consistency is the whole point: it lets a call originate on one operator’s IMS core and terminate on another’s without either side guessing how the other built its network.

IMS exists to collapse what used to be separate networks. Before it, voice ran on circuit-switched infrastructure, messaging rode its own signaling path, and any new service meant a new silo. IMS puts voice over LTE (VoLTE), video calling, and messaging on one IP core built around the Session Initiation Protocol, defined in RFC 3261. If you want the protocol itself before going further, our guide to SIP signaling fundamentals covers the layer that everything in IMS depends on. The short version: every session in IMS is set up, modified, and torn down with SIP, and the elements described below are mostly specialized SIP servers with defined jobs.

The IMS Architecture: Core Functional Elements

IMS is usually drawn as three horizontal planes. The access plane is where the device (the user equipment, or UE) connects. The control plane is the IMS core itself, where registration and session control happen. The application plane holds the service logic. Most of what makes IMS look complicated lives in the control plane, so that is where a voice engineer should focus.

The CSCF family

At the heart of the IMS core sit the Call Session Control Functions (CSCFs), the SIP servers that register users and route sessions. There are three, and they have distinct roles.

The Proxy-CSCF (P-CSCF) is the device’s first point of contact with the network. Every SIP message from the UE enters and leaves through the P-CSCF, which makes it the access border of the IMS core. It handles the security association with the device, compresses signaling where needed, and enforces policy at the edge.

The Interrogating-CSCF (I-CSCF) is the entry point into a home network from outside it. When a session needs to reach a subscriber, the I-CSCF queries the subscriber database to find out which serving node is handling that user, then forwards the request accordingly.

The Serving-CSCF (S-CSCF) is the brain of the core. It acts as the SIP registrar, holds the registration state for the subscriber, and runs the service triggers that decide which application logic a session touches. Every registered user is anchored to an S-CSCF for the duration of their registration.

The subscriber database and the gateways

The Home Subscriber Server (HSS) is the master database for the IMS core. It stores subscriber identities, authentication credentials, and service profiles, and the CSCFs query it over standardized interfaces during registration and session setup. Nothing routes correctly in IMS without the HSS confirming who a subscriber is and what they are allowed to do.

Three more functions handle the boundary between IMS and everything outside it. The Media Gateway Control Function (MGCF), paired with a media gateway, interworks calls between IMS and the legacy circuit-switched PSTN, translating both signaling and media. The Breakout Gateway Control Function (BGCF) decides where a call bound for the PSTN should break out, choosing the right MGCF or handing the call to another network. The Interconnection Border Control Function (IBCF) sits at the network-to-network interface (NNI) between one operator’s IMS and another’s, controlling signaling and media as it crosses the trust boundary.

Rounding out the core, the Media Resource Function (split into a controller, the MRFC, and a processor, the MRFP) provides announcements, conferencing, and media manipulation such as transcoding. The application plane holds the Application Servers (AS) where service logic actually runs, with the MMTel AS delivering telephony features and messaging servers handling SMS and RCS.

How a Session Moves Through the IMS Core

Registration comes first. The UE sends a SIP REGISTER that enters through the P-CSCF, which forwards it to the I-CSCF. The I-CSCF queries the HSS to learn which S-CSCF should serve this subscriber, assigns one, and the S-CSCF completes the registration after the HSS authenticates the user. From that point on, the network knows where the subscriber is and which serving node owns their session state.

Session setup follows the same path in spirit. A SIP INVITE from the device travels through the P-CSCF to the assigned S-CSCF, which evaluates service triggers and decides where the session goes next. If the destination is another subscriber on the same core, the S-CSCF routes inward. If the call is bound for the PSTN, the BGCF and MGCF take over the breakout. If it is bound for another operator, the IBCF carries it across the NNI. The message-level detail of how an INVITE negotiates and connects is the same SIP exchange you would see on any trunk, and our step-by-step SIP call flow walks through each message if you want the packet-level view.

Where the SBC Fits in IMS

For anyone who buys, deploys, or operates session border controllers, this is the part that matters. The IMS core has two borders that need a controlled, secured edge, and the SBC is what sits at both.

At the access border, the SBC performs (or fronts) the P-CSCF function for VoLTE and other access traffic. It handles NAT traversal for devices behind routers, anchors media so the network keeps control of the RTP path, manages registration toward the core, and enforces access security. This is the same role an access SBC plays in any IP voice network, applied to the specific signaling of an IMS access leg.

At the network-to-network border, the SBC performs the IBCF function between operators. Here it hides topology so neither operator exposes its internal addressing, normalizes SIP between the dialects each side speaks, applies denial-of-service and distributed denial-of-service protection at the edge, and handles media interworking. Where the two sides use different codecs, the border is also where transcoding happens, for example converting the AMR a mobile network uses to the G.711 a legacy trunk expects.

The reason IMS consolidation drives SBC demand comes down to leverage. Voice, video, SMS, and RCS all ride the same IMS core, so the border between that core and the outside world becomes the single highest-value point to secure, control, and adapt traffic. Messaging shares this infrastructure too: SMS and RCS terminate at the same edge that carries the voice. Whatever crosses the boundary, the SBC is where an operator gets to inspect, secure, and reshape it.

Frequently Asked Questions

Conclusion

IMS is the standardized IP core that lets a single network carry voice, video, and messaging instead of running each on its own infrastructure. Its CSCF and HSS control plane registers users and steers sessions, while the gateway functions handle breakout to the PSTN and interconnection to other operators. For a voice engineer, the practical takeaway is where the edges are: the access border and the network-to-network border are where the IMS core meets the rest of the world, and those are exactly the points a session border controller exists to secure and control.