IMS architecture explained: P-CSCF, I-CSCF, S-CSCF and the HSS

Why the roles are split at all

A plain SIP deployment can put registrar, proxy and application logic on one box. IMS — the 3GPP's IP Multimedia Subsystem, the architecture behind VoLTE and VoWiFi — splits them because a mobile operator has problems a PBX does not: subscribers who roam into other networks, a subscriber database that must survive any single node, services that must be applied consistently no matter where the user attaches, and a regulatory duty to control the edge. Each of those problems got its own function, and the functions talk standard SIP (with 3GPP extensions) on interfaces with two-letter names.

The cast

The interfaces worth memorising: Gm (phone to P-CSCF), Mw (CSCF to CSCF), Cx (I/S-CSCF to HSS, Diameter), ISC (S-CSCF to application server, SIP), Rx (P-CSCF to policy, Diameter). Most IMS trace questions are answered by knowing which interface you are looking at.

Registration, step by step

1. The phone sends REGISTER to the P-CSCF it discovered during attach. The request carries the private identity (IMPI) and public identity (IMPU), and a Security-Client header offering IPsec parameters.
2. The P-CSCF forwards it, adding a Path header — its own address — so the S-CSCF will later know to route everything for this user back through it.
3. The I-CSCF asks the HSS (Cx: UAR/UAA) whether the user exists and which S-CSCF should serve them, then forwards the REGISTER there.
4. The S-CSCF fetches authentication vectors from the HSS (Cx: MAR/MAA) and answers 401 Unauthorized with an AKA challenge — the WWW-Authenticate header carries RAND and AUTN. This first 401 is not a failure; it is the protocol working.
5. The SIM computes the response; the phone re-REGISTERs with it, now inside the negotiated IPsec associations. The S-CSCF verifies, stores the registration (Cx: SAR/SAA), downloads the user's service profile, and answers 200 OK carrying a Service-Route header — the route the phone must use for everything it sends from now on.
6. The S-CSCF then performs third-party registration: it sends its own REGISTER to each application server the filter criteria name, so the TAS knows the user is reachable.

How a call finds its services

The service profile downloaded at registration contains initial filter criteria (iFC): ordered rules that say "if a request matches this pattern, detour it to that application server first". When the user places a call, the S-CSCF walks the iFC list and chains the INVITE through each matching AS over ISC before routing it onward. This is why a single INVITE inside an operator core can appear four or five times in one capture with slightly different Route stacks — it is the same call being threaded through its service chain, not a loop. For the terminating side the same happens in reverse on the callee's S-CSCF.

What each box looks like in a trace

• P-CSCF fingerprints: Path on REGISTER, P-Asserted-Identity inserted after authentication, Security-Server in the 401, and the far side of the trace going quiet — beyond it everything is IPsec.
• S-CSCF fingerprints: Service-Route in the 200 OK to REGISTER, P-Charging-Vector with an icid-value that stays constant across the whole call — the single best correlation key in IMS, and Record-Route entries with its name.
• iFC at work: the same Call-ID reappearing with a growing Route set naming ...@tas... or similar — a service chain, not a retransmission (the CSeq and branch will differ; compare with real retransmissions).
• HSS trouble: invisible in SIP except as its consequences — REGISTER answered 403/404 for a valid user, or 504 when Cx times out. If you also have the Diameter capture, the Result-Code AVP in the UAA/MAA tells the real story.