Skip to main content

P-CSCF Operations & Reference

The Proxy-CSCF is the SIP entry point of the IMS for User Equipment. Every REGISTER and every session from the UE arrives here first. It establishes and enforces the access-security association that protects the UE's signalling, inserts itself into the routing path (Path on registration, record-route on sessions) so that all subsequent traffic - including terminating requests and in-dialog messages - traverses this node, detects the UE's access technology to drive media-bearer policy, and provides the emergency-session entry point (E-CSCF) with a usable calling-line identity per TS 23.167. It is a signalling proxy only: media flows directly between the UE and the terminating side and never through this node.

IMS Functions​

Registration proxy & IPsec security association​

The P-CSCF is the UE's registrar-facing proxy. It relays the REGISTER toward the home network (I-CSCF/S-CSCF), and on the challenge/response exchange it establishes an IPsec ESP security association with the UE as part of the IMS-AKA procedure. During registration the UE and the P-CSCF negotiate the SA parameters through the Security-Client / Security-Server headers; from the authenticated re-REGISTER onward, all signalling for that UE is carried inside the SA.

On the forwarded REGISTER the P-CSCF inserts a Path header so that terminating requests are routed back through this same node, forces the registration expiry to a network-controlled value, and advertises path support. On the successful 200 OK it stores the contact binding and caches the returned Service-Route and P-Associated-URI so subsequent requests are steered through the correct home-network path.

Each registered UE consumes one security association drawn from a per-deployment resource pool; the SA is released when the UE de-registers (expiry 0) or its registration lapses. A REGISTER whose Contact marks an emergency (;sos) registration is rejected - emergency sessions are handled directly on the INVITE, not via emergency registration.

Access detection & QoS / policy control​

Although it never relays media, the P-CSCF authorises the dedicated media bearer with the policy plane. It classifies the UE's access from the P-Access-Network-Info header (per TS 24.229 §5.2.6.3): LTE reports 3GPP-E-UTRAN, 5G NR reports 3GPP-NR. WiFi access is excluded from dynamic QoS as it has no dedicated bearer.

  • 4G / LTE - the media bearer QoS is authorised over Diameter Rx to the PCRF. On the answering leg (the 200 OK carrying SDP) the P-CSCF issues an Authorization/Authentication Request (AAR) describing the audio (and, where present, video) media flow; the PCRF installs the corresponding dedicated bearer. The authorisation is refreshed on in-dialog re-INVITEs and released when the dialog ends.
  • VoNR (5G NR) - the bearer QoS is authorised over the N5 interface to the PCF using the Npcf_PolicyAuthorization service. The P-CSCF acts as an Application Function: as the media is answered it creates an application session on the PCF (afAppId VoNR, an AUDIO media component with ENABLED flow status and a flow descriptor for the UE's media, plus an AF notification URI the PCF can call back on), and deletes that application session when the dialog ends.

The QoS authorisation runs on both the originating (MO) and terminating (MT) legs, keyed on the UE's own IP address. UE address binding: the UE address is encoded to match the PDU-session/bearer binding the policy node holds - an IPv6 UE is signalled as ueIpv6 and an IPv4 UE as ueIpv4; a v6 address placed in the v4 field never matches the PCF's binding and no dedicated bearer is installed.

For VoNR the P-CSCF locates the serving PCF via NRF discovery: it registers as an AF and, for each session, resolves the PCF bound to the UE's PDU session through the NRF→BSF chain. This is the only PCF discovery path.

Emergency calls (E-CSCF) & calling-line identity - TS 23.167​

The P-CSCF is the emergency entry point. It detects an emergency session by the emergency service URN (urn:service:sos) on the INVITE, and routes it directly to the emergency application server (bypassing the normal registration check). Because an emergency INVITE frequently carries no MSISDN, the P-CSCF supplies a usable calling-line identity for the PSAP - even for callers that are unknown or anonymous - per TS 23.167 Annex K and TS 29.214 §4.4.6a.

The identity is resolved by two complementary mechanisms:

  1. Cached IMEI→MSISDN binding (fast path). On each successful REGISTER the P-CSCF caches a binding of the UE's IMEI (from the Contact +sip.instance) to the MSISDN (from P-Associated-URI). The binding is replicated across all P-CSCF nodes, so any node can resolve the identity regardless of where the UE registered. On the emergency INVITE the P-CSCF extracts the IMEI and looks up the cached MSISDN.
  2. Asynchronous subscription query (unknown/anonymous callers). If there is no cached binding, the P-CSCF issues an asynchronous Rx subscription query to the PCRF keyed on the UE's source IP address, suspending the INVITE until the answer returns. The PCRF returns the EPC-level identities, from which one is chosen by precedence MSISDN → IMSI → IMEISV (an IMEISV result is cached back for reuse).

The resolved identity is asserted as the caller's From URI and as a P-Asserted-Identity on the sos.apn domain, and is restored consistently on replies and in-dialog requests, so the PSAP sees a usable callback identity even for an originally anonymous caller. Whichever path resolves the identity, the emergency INVITE then receives the same media/QoS and header treatment as any other originating request before being forwarded to the emergency application server.

Security / anti-flood​

The P-CSCF applies source-based flood protection: requests are rate-limited per source IP, and an IP that exceeds the sampling threshold is banned for a hold-off period. Failed registration authentication is tracked per source IP in a short-lived counter; a source that exceeds the failed-attempt threshold within the window is banned, frustrating credential-guessing. Requests that a UE addresses to the node itself, and malformed messages, are dropped. Under memory pressure the node sheds new requests with 503.

Cluster replication​

Registration-related and emergency state is replicated across P-CSCF nodes. In particular the IMEI→MSISDN emergency binding is synchronised between nodes (with a full sync on start-up), so any node in the cluster can serve terminating traffic and resolve emergency-call identity regardless of which node originally registered the UE - no per-node provisioning is required.

Deployment Configuration (Ansible-injected)​

Ansible renders the P-CSCF's runtime configuration and its Diameter peer table (pcscf.xml) at deploy time. Most values derive from the network's PLMN identity (MCC/MNC) and the node's inventory hostname; the 5G SBI and PCF blocks are emitted only when the deployment inventory contains the relevant network functions.

Identity​

NameWhat it controlsValue / derivation
NETWORKNAMEHome IMS domain used in P-Visited-Network-ID and identity rewritesims.mnc<mnc>.mcc<mcc>.3gppnetwork.org
HOSTNAMEThis node's FQDN (also its host alias)<inventory_hostname>.ims.mnc<mnc>.mcc<mcc>.3gppnetwork.org
URIThe P-CSCF's own SIP URIsip:<hostname>:5060
PCSCF_URLSource URI used for NAT-keepalive OPTIONS pingssip:<hostname>:5060
PCSCF_USER_AGENTUser-Agent header the node emitsUser-Agent: Omnitouch Proxy-CSCF <inventory_hostname>
PCSCF_SERVERServer header the node emitsServer: Omnitouch Proxy-CSCF <inventory_hostname>
DMQ_NOTIFICATION_ADDRCluster notification address for state replication between P-CSCF nodessip:pcscf.ims.mnc<mnc>.mcc<mcc>.3gppnetwork.org:5090

The SIP listen sockets (UDP/TCP 5060, plus IPv6 5060 where an IPv6 address is defined) and the Prometheus HTTP socket (TCP 9090) are templated from the inventory host address. The P-CSCF fronts UEs on IPv6 where available while peers behind it remain IPv4. The PATH_HEADER and P_VISITED_NETWORK_ID_HEADER are likewise built from the hostname and PLMN.

Rx / policy control (4G)​

NameWhat it controlsValue / derivation
RX_DEST_REALMDiameter destination realm for Rx toward the PCRF{{ diameter_realm }}
PCRF_REALMPCRF realmepc.mnc<mnc>.mcc<mcc>.3gppnetwork.org
RX_AF_SIGNALING_IPAF-signalling IP carried in the Rx AAR (this P-CSCF)node ansible_host (override only for double-NAT)
RX_IMS_REG_DIALOG_DIRECTIONDialog-direction mode for Rx registration3

Fixed Rx media parameters include video authorisation on, a 64 kbit/s default/minimum audio bandwidth, RTCP flow inclusion, and a 24-hour maximum authorised session.

5G SBI / PCF (VoNR)​

Emitted when the deployment inventory contains a PCF and an NRF.

NameWhat it controlsValue / derivation
VONR_AF_NOTIF_URIAF notification endpoint the PCF calls back onhttp://<this host>:<pcscf_af_notif_port|9999>/af
NRF_URINRF base URI for AF registration and discoveryhttp://<nrf host>:<nrf_sbi_port|7777>
IMS_NRF_NF_IPV4This P-CSCF's NF IPv4 for its AF registrationnode ansible_host
IMS_NRF_PLMN_MCC / IMS_NRF_PLMN_MNCPLMN advertised in NRF registration/discoveryfrom plmn_id

PCF discovery: the P-CSCF registers with the NRF as an AF and, for each VoNR session, resolves the PCF bound to that UE's PDU session via the NRF→BSF chain - so app-sessions always reach the correct per-subscriber PCF, including in multi-PCF 5G cores. This is the only supported discovery path.

Sizing / transport​

NameWhat it controlsValue
CAPTURE_NODEHomer SIP-capture target (templated only when Homer capture is enabled)sip:<homer host>:9060

The number of SIP (UDP) worker processes and the registrar hash-table size are tuned in the base configuration for the deployment scale; iOS UEs get a shortened TCP connection lifetime to accommodate their transport behaviour.

Diameter peer configuration​

The P-CSCF's Diameter peer table (pcscf.xml) advertises the Rx application (16777236) toward the PCRF. The file structure and the Ansible variables that fill it are shared across all CSCFs - see Diameter → Peer Configuration (Deployment). Rx is only active when WITH_RX is defined.

Troubleshooting​

Registration / IPsec connectivity​

Users unable to register, or registration timeouts, often point to the P-CSCF's access-security or discovery layer rather than the home network:

  • IPsec SA establishment - mobile devices must complete the IMS-AKA Security-Client / Security-Server negotiation. If the authenticated re-REGISTER never arrives inside the SA, check that the UE and P-CSCF agreed on SA parameters and that no middlebox is stripping the security headers.
  • NAT traversal - for devices behind NAT, verify the far-end NAT handling and that keepalive OPTIONS pings are reaching the UE, so the pinhole for terminating traffic stays open.
  • P-CSCF discovery - verify the UE is discovering the correct P-CSCF address (via DNS, DHCP, or static configuration) and that the SIP listen sockets are reachable on the access network.

Emergency call issues​

Symptoms: Emergency calls not routing to the PSAP, or the PSAP receives no usable calling-line identity (CLI) / callback number.

  • Emergency detection - the P-CSCF routes on the emergency service URN (urn:service:sos), plus the dialled emergency numbers. Confirm the INVITE carries the expected emergency indication and that emergency routing bypasses the normal registration check.
  • CLI resolution for anonymous / unknown callers - the caller's identity is supplied from the cached IMEI→MSISDN binding (cluster-replicated, 4-hour TTL). For a caller with no cached binding, the P-CSCF falls back to an asynchronous Rx subscription query to the PCRF, keyed on the UE source IP, resolving an EPC identity by precedence MSISDN → IMSI → IMEISV (TS 23.167 Annex K). If the PSAP sees an anonymous caller, verify the binding was cached at registration, or that the Rx subscription query returned an identity. The cached binding map is viewable in OmniWeb.
  • Location availability - verify location information is available for E911/E112 and that the location retrieval leg (LRF) is reachable.
  • Test routing - emergency call routing can be exercised without an actual PSAP connection to confirm detection, identity assertion on the sos.apn domain, and routing to the emergency application server.

Emergency sessions succeed even for unregistered users, users with no SIM / invalid credentials, and roaming users. See Emergency calls (E-CSCF) & calling-line identity - TS 23.167 for the underlying mechanism.

Call Flows​

The sequence diagrams are embedded with the functions they document, plus the full session ladders below:

Mobile Originating call (MO)​

Originating calls are routed through the S-CSCF (via the cached Service-Route) to the TAS for service logic and charging; media stays direct.

Mobile Terminating call (MT)​

Terminating calls arrive back through the P-CSCF recorded in the Path at registration; QoS is authorised as the called UE answers.

Last updated on