Skip to main content

P-CSCF/E-CSCF Operations Guide

Table of Contents​

  1. Overview
  2. Role in IMS Architecture
  3. P-CSCF Functions
  4. E-CSCF Functions
  5. Web UI Operations
  6. Call Flows
  7. Troubleshooting

Overview​

The P-CSCF (Proxy Call Session Control Function) is the first point of contact for User Equipment (UE) in the IMS network. It serves as an edge proxy that handles security, QoS enforcement, and emergency call routing. In this implementation, the P-CSCF also functions as the E-CSCF (Emergency CSCF) for emergency services.

Important: In our deployments, P-CSCF does not relay media by default. Media flows directly between the UE and OmniTAS (Telephony Application Server) or other media endpoints. The P-CSCF is purely a SIP signaling proxy.

3GPP Specifications​

  • 3GPP TS 23.228: IP Multimedia Subsystem (IMS) Stage 2
  • 3GPP TS 24.229: IMS Call Control Protocol
  • 3GPP TS 33.203: Access security for IMS
  • 3GPP TS 23.167: IP Multimedia Subsystem (IMS) emergency sessions

Key Responsibilities​

  1. First Contact Point: UE's initial SIP proxy in IMS
  2. Security Enforcement: IPsec tunnel establishment and management
  3. QoS Control: Interfaces with PCRF via Rx for policy enforcement
  4. Emergency Services: Routes emergency calls and provides IMEI-to-MSISDN lookup (E-CSCF function)
  5. Compression: SigComp support for bandwidth optimization
  6. Transport Support: Supports UDP and TCP

Role in IMS Architecture​

Network Position​

3GPP Reference Points​

InterfaceProtocolPurposeConnected To
GmSIP/IPsecUE to P-CSCFUser Equipment
MwSIPP-CSCF to I-CSCF/S-CSCFCore IMS
RxDiameterQoS/Policy controlPCRF
MlHTTP/HELDLocation retrievalLRF (E-CSCF)
MgSIPEmergency callsMGCF/E-CSCF

P-CSCF Functions​

1. Registration Handling​

The P-CSCF is the first hop for SIP REGISTER messages from UEs.

Registration Flow​

Key Features​

Path Header Insertion:

Path: <sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;lr>
  • Ensures subsequent requests route back through P-CSCF
  • Required per RFC 3327 for IMS

Registration Timer Enforcement:

  • Forces registration expiry to 599 seconds
  • Overrides UE-requested values for network control

IMEI Extraction:

  • Extracts IMEI from Contact header: +sip.instance="<urn:gsma:imei:...>"
  • Stores in hash table for emergency call mapping

Transport-Specific Handling:

  • iOS devices: Extends TCP lifetime to prevent premature disconnection

2. Security Functions​

IPsec Tunnel Management​

The P-CSCF establishes IPsec ESP tunnels with UEs for secure SIP signaling.

IPsec Configuration:

The IPsec functionality is configured with the following parameters:

  • Listen address: 10.4.12.165 (P-CSCF's IP address for IPsec endpoints)
  • Client port (base): 5100 (starting port for UE → P-CSCF traffic)
  • Server port (base): 6100 (starting port for P-CSCF → UE traffic)
  • Port range: Configurable pool of ports (typically 1000-10000 ports)
  • SPI ID start: 4096 (starting value for Security Parameter Index allocation)
  • SPI ID range: 100000 (number of SPI pairs available for allocation)
  • Max connections: 20 (maximum concurrent IPsec security associations per worker)

SPI and Port Management​

Each IPsec tunnel between a UE and the P-CSCF requires unique identifiers to keep traffic separated and secure. The system manages two types of resources:

Security Parameter Indexes (SPIs):

Each IPsec tunnel uses TWO SPIs - one for each direction:

  • spi-c (client SPI): Identifies packets sent from UE to P-CSCF
  • spi-s (server SPI): Identifies packets sent from P-CSCF to UE

SPIs are allocated in pairs from a configured pool. The system is typically configured with:

  • Starting SPI value: 4096
  • Available range: 100,000 SPI values
  • This provides capacity for 50,000 simultaneous tunnels (pairs are allocated as consecutive even/odd numbers)

Port Allocation:

Each tunnel also uses unique UDP ports on the P-CSCF:

  • client port: P-CSCF port where it receives IPsec packets from the UE
  • server port: P-CSCF port where it sends IPsec packets to the UE

Typical port configuration:

  • Client port starting value: 5100
  • Server port starting value: 6100
  • Port range: 10,000 ports available
  • Ports wrap around to the start when the range is exhausted

How Resource Allocation Works:

When a UE registers and requests IPsec protection:

  1. First Registration: Gets spi-c=4096, spi-s=4097, client port=5100, server port=6100
  2. Second Registration: Gets spi-c=4098, spi-s=4099, client port=5101, server port=6101
  3. Third Registration: Gets spi-c=4100, spi-s=4101, client port=5102, server port=6102

And so on...

After 10,000 registrations, the ports wrap back to the beginning (5100, 6100), while SPIs continue incrementing. This allows for more tunnels than available ports, as long as UEs have different IP addresses.

Resource Limits:

The maximum number of simultaneous IPsec tunnels is determined by whichever limit is hit first:

  • SPI range capacity (typically 50,000 pairs)
  • Port range capacity (typically 10,000 ports)
  • System memory and processing capacity

Monitoring via Web UI:

Navigate to P-CSCF page → IPsec Statistics (if available) to view:

  • Number of active IPsec tunnels
  • Number of available SPI/port pairs
  • Utilization percentage

If you see registration failures with IPsec-related errors, it may indicate:

  • SPI pool exhaustion (all 50,000 pairs in use)
  • Port pool exhaustion (all 10,000 ports in use)
  • Old tunnels not being cleaned up properly

When Resources Are Released:

SPIs and ports are returned to the available pool when:

  • A UE de-registers (sends REGISTER with Expires: 0)
  • A registration expires without being refreshed
  • An IPsec tunnel is manually destroyed via the web interface
  • System administrator cleans up stale tunnels

Capacity Planning:

For deployment planning:

  • Each active tunnel uses approximately 1KB of memory
  • Typical production deployment supports 10,000-50,000 simultaneous tunnels
  • Monitor utilization trends to predict when capacity expansion is needed
  • If regularly exceeding 80% utilization, coordinate with system administrators to increase SPI/port ranges

Security Association (SA) Setup:

  1. UE sends REGISTER with Security-Client header:

    Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; ealg=null;
                     spi-c=12345; spi-s=67890; port-c=5100; port-s=6100

  2. P-CSCF responds with Security-Server:

    Security-Server: ipsec-3gpp; alg=hmac-sha-1-96; ealg=null;
                     spi-c=11111; spi-s=22222; port-c=5100; port-s=6100

  3. P-CSCF creates IPsec policies using setkey:

    # Client to Server
    spdadd <ue-ip>[5100] <pcscf-ip>[6100] any -P out ipsec esp/transport//require;

    # Server to Client
    spdadd <pcscf-ip>[6100] <ue-ip>[5100] any -P in ipsec esp/transport//require;

  4. All subsequent SIP messages use IPsec tunnel

Supported Algorithms:

  • Authentication: hmac-md5-96, hmac-sha-1-96
  • Encryption: null, des-ede3-cbc, aes-cbc (preferred: null for LTE)

3. Media Handling​

Important Note: In our deployments, the P-CSCF does NOT relay media by default. Media (RTP/SRTP) flows directly from the UE to OmniTAS (Telephony Application Server) or other media endpoints. The P-CSCF handles only SIP signaling.

Media flows directly between UEs and the OmniTAS (Telephony Application Server), bypassing the P-CSCF entirely for RTP/SRTP traffic:

UE <------ SIP ------> P-CSCF <------ SIP ------> S-CSCF <------ SIP ------> OmniTAS
    <----------------------- RTP/SRTP (direct to TAS) ---------------------->

The P-CSCF handles only SIP signaling. All media (voice, video) is established directly between the UE and OmniTAS.

4. QoS and Policy Enforcement (Rx Interface)​

Diameter Rx Integration​

Purpose: Coordinate QoS with PCRF for bearer establishment

Diameter Configuration:

The P-CSCF connects to the PCRF via Diameter on port 3868 using the Rx application (Application ID 16777236, 3GPP Vendor ID 10415).

Rx Operations:

  1. AAR (Authorization Authentication Request): Request QoS for media flow
  2. AAA (Authorization Authentication Answer): PCRF grants/denies
  3. STR (Session Termination Request): Release QoS on call end

AAR Message Flow​

Media Information Sent to PCRF:

  • Flow description (IP, port, protocol)
  • Bandwidth requirements (uplink/downlink)
  • Media type (audio, video)
  • Flow status (enabled, disabled)

5. Anti-Flood Protection​

Pike Module Configuration (Rate Limiting): The pike module provides flood protection with these settings:

  • Sampling time unit: 2 seconds - time window for measuring request rate
  • Requests density per unit: 16 requests allowed per 2-second window from a single IP
  • Remove latency: 300 seconds (5 minutes) - duration an IP is blocked after exceeding the limit

Failed Authentication Tracking: The P-CSCF tracks failed authentication attempts to prevent brute force attacks:

  • Maintains a hash table counter for failed authentication attempts per source IP
  • Increments counter on authentication failure with 120-second expiry
  • If an IP exceeds 10 failed attempts within 120 seconds, blocks the IP with 403 Too Many Failed Attempts
  • Prevents attackers from guessing user credentials

E-CSCF Functions​

The P-CSCF includes E-CSCF functionality for emergency call handling.

Emergency Call Detection​

SIP URIs Recognized:

  • urn:service:sos (general emergency)
  • urn:service:sos.police
  • urn:service:sos.ambulance
  • urn:service:sos.fire
  • urn:service:sos.marine
  • urn:service:sos.mountain

Detection Logic: Emergency calls are detected by examining the Request-URI:

  • Checks if the method is INVITE (call setup request)
  • Checks if the Request-URI matches emergency patterns:
    • URN format: urn:service:sos* (SOS URNs defined in RFC 5031)
    • North American emergency: 911
    • European/International emergency: 112
  • If emergency call is detected, routes to EMERGENCY handling block for special processing

IMEI to MSISDN Mapping for Emergency Calls​

Why This Is Needed: When users make emergency calls (e.g., 911, 112, urn:service:sos), the UE often does not provide the MSISDN (phone number) in the SIP message. Emergency services (PSAP - Public Safety Answering Point) need to know the caller's phone number for callback purposes. To solve this, the P-CSCF/E-CSCF maintains a mapping from IMEI (device identifier) to MSISDN.

How It Works:

  1. During Registration (when MSISDN is known):

    • Extracts IMEI from Contact header's +sip.instance parameter (format: urn:gsma:imei:123456-78-901234-5)
    • Extracts MSISDN from the user's public identity (IMPU) in the From header username
    • Stores the IMEI → MSISDN mapping in a hash table with 24-hour TTL (86400 seconds)
    • Example: imei_msisdn["urn:gsma:imei:123456789012345"] = "12015551234"
    • In clustered deployments: Automatically replicates the mapping to all other P-CSCF nodes in the cluster

  2. During Emergency Call (when MSISDN might be missing):

    • Extracts IMEI from the emergency call's Contact header +sip.instance parameter
    • Performs hash table lookup to retrieve the MSISDN associated with this IMEI
    • If MSISDN is found in the mapping:
      • Adds P-Asserted-Identity header with the full MSISDN (sip:+12015551234@domain)
      • This provides the PSAP with the callback number for the emergency caller

High Availability - Multi-Node Synchronization:

In production deployments with multiple P-CSCF nodes for redundancy, the IMEI→MSISDN mappings are automatically synchronized across all nodes:

Cluster Replication Behavior:

When a UE registers on P-CSCF Node 1:

  1. Node 1 creates the IMEI→MSISDN mapping locally
  2. Node 1 immediately broadcasts the mapping to all other P-CSCF nodes in the cluster
  3. P-CSCF Node 2, Node 3, etc. receive the update and create identical local copies
  4. All nodes now have the same IMEI→MSISDN mapping

Why This Matters:

If a UE registered through P-CSCF Node 1 but makes an emergency call that gets routed to P-CSCF Node 2 (due to load balancing or failover), Node 2 already has the IMEI→MSISDN mapping and can provide the callback number to the PSAP.

Synchronization Mechanism:

The synchronization happens via SIP-based messaging between P-CSCF nodes:

  • Uses custom SIP messages to propagate hash table updates
  • Messages are sent in JSON format containing the IMEI, MSISDN, and TTL
  • Transmission is automatic and transparent - no operator intervention needed
  • Updates are broadcast to all cluster members within milliseconds

Operations Impact:

  • Resilience: Emergency calls work correctly regardless of which P-CSCF node handles the call
  • No Single Point of Failure: Any P-CSCF node can provide callback number for any registered UE
  • Automatic: Synchronization is built-in and requires no manual configuration or intervention
  • Monitoring: Via web UI, navigate to P-CSCF → Hash Tables → imei_msisdn to see mappings on each node

Cluster Configuration Requirements:

For hash table synchronization to work:

  • All P-CSCF nodes must be configured with each other's addresses
  • Nodes discover each other automatically through availability notifications
  • Network connectivity must allow SIP traffic between all P-CSCF nodes
  • If synchronization fails, check that firewall rules allow inter-node communication

Example Scenario:

1. User registers: IMEI=123456789012345, MSISDN=12015551234
   → Stored: imei_msisdn[123456789012345] = 12015551234

2. User dials 911: INVITE urn:service:sos (MSISDN not in From header)
   → P-CSCF extracts IMEI from Contact: 123456789012345
   → P-CSCF looks up: imei_msisdn[123456789012345] → 12015551234
   → P-CSCF adds header: P-Asserted-Identity: <sip:+12015551234@...>
   → PSAP receives call with callback number: +12015551234

Emergency Routing​

Emergency Call Features:

  • Bypasses registration check
  • Adds PIDF-LO (Presence Information Data Format - Location Object)
  • Routes to emergency application server or PSAP
  • Priority handling (preempts normal calls)
  • Location information from LRF or UE

Web UI Operations​

Accessing P-CSCF Page​

Navigate to: https://<control-panel>/pcscf

Page Layout​

The P-CSCF page has three main tabs:

  1. Registered Contacts - Active registrations
  2. User Location - Search by IMSI/IP
  3. Hash Tables - Shared memory tables

Viewing Registered Contacts​

Display Columns:

  • AoR (Address of Record): User's SIP identity
  • Contact: Device contact URI
  • Expires: Registration expiry timestamp
  • Public IP: UE's public IP address
  • Received: Actual received IP (if different from Contact)
  • Path: Path header for routing
  • Rx Session ID: Diameter Rx session (if QoS active)

Features:

  • Auto-refresh every 5 seconds
  • Search by partial AoR or Contact
  • Sort by column (click header)
  • Expandable rows for full details

Example Output:

AoR: sip:12015551234@ims.mnc001.mcc001.3gppnetwork.org
Contact: sip:12015551234@10.4.12.100:5060;transport=udp
Expires: 2025-11-29 14:30:15
Public IP: 10.4.12.100
Received: 10.4.12.100:52341
Path: <sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;lr>
Rx Session: rx-pcscf-session-12345

Searching User Location​

Search Options:

  • By IMSI: imsi:310150123456789
  • By IP: 10.4.12.100

Use Cases:

  1. Find which user is using a specific IP
  2. Check if IMSI is registered
  3. Verify IPsec tunnel status
  4. Check service routes

Hash Table Management​

Common Tables:

TablePurposeTypical Size
imei_msisdnEmergency IMEI→MSISDN mapping100-1000 entries
service_routesCached service routesPer-registration
dialog_outOutbound dialog trackingPer-call

Operations:

  • List Tables: Click "Hash Tables" tab
  • Dump Table: Click table name to view contents
  • Delete Entry: Click "Delete" next to entry
  • Flush Table: Click "Flush" to clear entire table (use caution!)

Example Entry:

Key:   urn:gsma:imei:123456-78-901234-5
Value: 310150123456789
TTL:   86400 seconds (24 hours)

Call Flows​

Mobile Originating Call (MO)​

All originating calls are routed through the TAS (OmniTAS) for service logic and charging:

Mobile Terminating Call (MT)​

Terminating calls also go through TAS for service logic:

Emergency Call Flow​

Troubleshooting​

Registration Issues​

UE Cannot Register​

Symptoms: UE gets 408 Timeout or no response

Diagnostic Steps:

  1. Check registration status via the control panel:

    • Navigate to P-CSCF page
    • Check "Registered Contacts" tab
    • Verify user appears in the list

  2. Review system logs via the control panel Logs page for errors

  3. Verify network connectivity between UE and P-CSCF

  4. Check firewall rules allow SIP traffic (port 5060 UDP/TCP)

  5. Coordinate with system administrators if P-CSCF service appears to be down

IPsec Tunnel Not Established​

Symptoms: 401 challenge sent but re-REGISTER fails

Diagnostic Steps:

  1. Review system logs via the control panel Logs page for IPsec-related errors

  2. Verify UE is sending Security-Client header in initial REGISTER

  3. Check that UE is using IPsec ports (5100 client, 6100 server) in re-REGISTER

  4. Verify received address matches expected IPsec tunnel endpoint

  5. Coordinate with system administrators to verify IPsec kernel modules are loaded and no port conflicts exist

Call Issues​

Calls Don't Route to UE​

Symptoms: INVITE to P-CSCF but UE doesn't ring

Diagnostic Steps:

  1. Verify registration exists via the control panel:

    • Navigate to P-CSCF page
    • Check "Registered Contacts" tab
    • Search for the user and verify registration is active

  2. Verify Path header was stored in the registration

  3. Check that calls are being sent to the correct contact address

  4. Review system logs for routing errors

  5. Verify network path from P-CSCF to UE is reachable

One-Way Audio​

Symptoms: One party can't hear the other

Note: In our deployments, P-CSCF does not relay media. Media flows directly between UE and OmniTAS. If you're experiencing one-way audio, the issue is likely at the endpoints or in the network routing, not at the P-CSCF.

Diagnostic Steps:

  1. Verify SDP in INVITE/200 OK contains correct IP addresses and ports (review via system logs or packet capture if available to administrators)

  2. Verify firewall rules allow RTP/SRTP traffic between UE and OmniTAS

  3. Check NAT configuration if UE is behind NAT

  4. Verify OmniTAS media endpoint is reachable from UE (network connectivity)

  5. Coordinate with system administrators for packet capture analysis if needed

Emergency Calls Fail​

Symptoms: urn:service:sos calls rejected

Diagnostic Steps:

  1. Verify IMEI→MSISDN hash table via the control panel:

    • Navigate to P-CSCF → Hash Tables tab
    • Check imei_msisdn table contains entries
    • Verify the caller's IMEI has a mapping

  2. Test with a registered user making an emergency call first (to isolate registration vs. emergency routing issues)

  3. Review system logs via the control panel Logs page for emergency routing errors

  4. Verify emergency Application Server configuration

  5. Coordinate with system administrators to review emergency route configuration if needed

Performance Issues​

High CPU Usage​

Possible Causes:

  • Too many registrations
  • Pike anti-flood triggering
  • Database slow queries

Solutions:

  1. Check registration count via the control panel:

    • Navigate to P-CSCF → Registered Contacts tab
    • Review total number of active registrations

  2. Review system logs for Pike anti-flood blocks

  3. Coordinate with system administrators to scale horizontally (add more P-CSCF instances) if needed

High Memory Usage​

Possible Causes:

  • Hash table growth
  • Dialog table not being cleared
  • Memory leak

Solutions:

  1. Review hash tables via the control panel:

    • Navigate to P-CSCF → Hash Tables tab
    • Check table sizes and entry counts

  2. Clear old entries via the control panel:

    • Select problematic hash table
    • Use "Flush" operation if needed (use with caution - clears entire table)

  3. Coordinate with system administrators to restart the P-CSCF service if memory leak is suspected

Diameter/Rx Issues​

PCRF Peer Closed​

Symptoms: Diameter peer shows "Closed" state in Web UI

Diagnostic Steps:

  1. Check Diameter peer status via the control panel:

    • Navigate to Diameter page
    • Select P-CSCF node
    • Verify PCRF peer state (should be "I_Open" when connected)

  2. Verify network connectivity to PCRF (coordinate with network team if needed)

  3. Try to enable peer via the control panel:

    • Navigate to Diameter page
    • Find PCRF peer
    • Click "Enable" button

  4. Review system logs via the control panel Logs page for Diameter connection errors

  5. Coordinate with system administrators to verify Diameter configuration if needed

QoS Not Working​

Symptoms: Calls connect but no QoS bearer established

Diagnostic Steps:

  1. Review system logs via the control panel for AAR (Authorization Authentication Request) and AAA (Authorization Authentication Answer) messages

  2. Check PCRF response result code (should be 2001 for success)

  3. Verify PCRF peer is connected (see previous section)

  4. Verify media information in SDP is being correctly sent to PCRF

  5. Coordinate with system administrators to verify QoS configuration if needed

Best Practices​

Security​

  1. Always use IPsec for mobile devices (LTE/5G)
  2. Enable TLS for fixed/enterprise clients
  3. Configure anti-flood (Pike) for DoS protection
  4. Limit failed auth attempts to prevent brute force
  5. Use strong ciphers for TLS (disable SSLv2/v3)
  6. Regularly rotate IPsec keys (via re-registration)

Performance​

  1. Tune hash_size based on expected registrations:

    • 1,000 users: hash_size=10 (creates 2^10 = 1,024 hash buckets)
    • 10,000 users: hash_size=13 (creates 2^13 = 8,192 hash buckets)
    • 100,000 users: hash_size=16 (creates 2^16 = 65,536 hash buckets)

  2. Adjust worker processes based on CPU cores:

    • Set children to match number of CPU cores for SIP processing
    • Set tcp_children to 2× CPU cores for TCP connection handling

  3. Use mlock_pages to prevent swapping:

    • Enable mlock_pages=yes to lock shared memory pages in RAM
    • Prevents performance degradation from memory swapping to disk

  4. Disable DNS cache for IMS environments:

    • Set dns_cache_init=off to use fresh DNS lookups
    • Necessary for dynamic DNS SRV-based load balancing

  5. Enable SRV load balancing:

    • Set dns_srv_lb=yes to distribute traffic across multiple servers
    • Uses DNS SRV records for automatic load distribution

Monitoring​

  1. Enable Prometheus metrics (port 9090 in config) - See Metrics Reference for all available P-CSCF metrics
  2. Monitor registration count trends
  3. Track Diameter peer health (Rx to PCRF)
  4. Alert on high error rates in logs
  5. Monitor dialog count (active sessions)
  6. Check memory usage regularly

High Availability​

  1. Deploy multiple P-CSCF instances

  2. Use DNS SRV for load balancing:

    _sip._udp.pcscf.example.com. SRV 10 50 5060 pcscf01.example.com.
    _sip._udp.pcscf.example.com. SRV 10 50 5060 pcscf02.example.com.

  3. Avoid state where possible (stateless proxy)

  4. Use shared database for persistent data (if needed)

  5. Monitor via web interface using control panel health checks

Emergency Services​

  1. Always allow emergency calls even if unregistered
  2. Store IMEI→MSISDN mapping during registration
  3. Set TTL for emergency hash table (86400 = 24 hours)
  4. Test regularly with test PSAP
  5. Ensure LRF connectivity for location
  6. Priority handling for emergency calls

Reference​

Additional Technical Resources​

For system administrators and developers, technical module documentation is available online for the underlying software components.

3GPP Specifications​

  • TS 23.228: IMS Architecture
  • TS 24.229: IMS SIP Profile
  • TS 33.203: Access Security
  • TS 23.167: Emergency Services
  • TS 29.214: Rx Interface (PCRF)

RFCs​

  • RFC 3261: SIP
  • RFC 3327: Path Header
  • RFC 3608: Service-Route Header
  • RFC 3GPP-IMS: P-Headers (P-Asserted-Identity, etc.)
  • RFC 5626: Outbound (connection management)