Emergency Registration

The SBC Core acting as a P-CSCF supports the following Emergency-CSCF (E-CSCF) functionality:

• Supports registration requests with an emergency registration indication like any other registration request, except that the SBC may reject an emergency registration request if the system that the P- CSCF belongs to does not support emergency sessions for the UE (for example, due to operator policy or UE not within IM CN subsystem's geographical area).
• Detects an emergency session establishment request.
• Prevents non-emergency requests that are associated with an emergency registration.
• Selects an E-CSCF in the same network to handle the emergency session request.
• For non-roaming subscribers, forwards an emergency session to an S-CSCF if  instructed by operator policy or local regulation.
• For UEs without credentials, forwards the equipment identifier to the E-CSCF that was received from the UE.
• Prioritizes emergency sessions.

Emergency Registration Overview

For an IMS emergency registration, the UE includes "sos" SIP URI parameter in the Contact Header field. This indicates that it is an emergency registration and that the associated contact address is allowed only for emergency service. In this case, the roaming and barring restrictions are not applied for the registered address-of-record. A registration received with a "sos" parameter in the contact header is considered to be an emergency registration if the control "sosInContactOfRegister" is set to enabled on the emergency call profile, which is configured on the ingress trunk group.

For example, Contact: <sip:ua1@10.32.241.3:11301;sos>

If passCompleteContactHeader is enabled and the received contact contains "sos" then the "sos" parameter is transparently sent out in the egress REGISTER. If the transparency control is not enabled, but the SBC considers this an emergency registration, the "sos" parameter is added in the contact on the egress registration. An emergency registration cannot be deleted. 

Call Flow Example of SBC Acting as P-CSCF

Emergency Registration CAC

The SBC supports oversubscription of resources for emergency registrations.The control is configured on a per zone / IPTG basis using the values “unlimited” or 0 - 1000 percent. The default is 10. This factor gives priority to emergency registrations in terms of registration limit and registration rate.

Emergency Registration Congestion Handling

Emergency registrations and emergency calls use the same congestion handling mechanism. There is no extra configuration to support this, but if an emergency registration is received on a system under overload, the configured system congestion preference, initialSipRegister, is ignored and the emergency registration message is given priority and if possible, is accepted.

Emergency Session Handling and Release Scenarios

The SBC acting as a P-CSCF handles emergency sessions and other requests from both the registered user, which includes normal and emergency registrations, and the unregistered user. The SBC is configured to accommodate variations in networks and what they support.

The SBC includes a SIP Trunk Group control  “emergencyCallHandlingMode” with the following options:

• rejectWith380 – If set and and emergency call is received, then a "380" message with P-Asserted-Id header and an xml body with <type> set to “emergency” and <reason> is set to “Not capable of handling Emergency Sessions” is sent.

Emergency Session Routing

The SBC acting as a P-CSCF must re-route (or crankback) on the following emergency call responses using the Crankback profile which is applied to the ingress Trunk Group.

Resource Priority Header

The Resource-Priority Header (RPH) is used to mark SIP calls as priority calls and is only included in a request or response forwarded to another entity within the trust domain. When configured to do so, the P-CSCF inserts the Resource-Priority Header field with appropriate namespace and priority in the emergency request being sent out.

On the egress, the Resource-Priority header profile associated with the request leg determines whether to add the header and how to configure it. The profile is configured to add a namespace of “esnet” and the priority-value for the namespace. The RPH profile is associated with the emergency profile, which means an emergency profile must be associated with the egress trunk group.

The resource priority header profile format which the SBC includes in the egress message is as follows:

Resource-Priority: esnet.1

The SBC removes the RPH header if it is received in the incoming REGISTER from the UE.

% set profiles services emergencyCallProfile <ECP_name> resPriorityHeaderProfile <RPH_name>

Emergency Call Profile

The SBC supports configuring up to 32 emergency number prefixes and up to 10 service URNs in an Emergency Call Profile. If an incoming SIP INVITE has a R-URI with a prefix that matches one of the configured prefixes, or the R-URI contains a service URN configured in the urnPrefix table, the SBC treats the INVITE as an emergency session establishment. Refer to Emergency Call Profile - CLI for configuration details.

PCRF Communication

As part of the emergency call handling in IMS, the PCRF is instructed to mark the associated call as an emergency. This allows the policy decisions on the PCRF to make special provisions for emergency calls. 

The SBC implements the Rx interface to the PCRF to send and receive authorization requests and responses. The following functionality is also supported:

1. Include the SERVICE URN AVP parameter, coded as per the received URN with “urn:service:” omitted, in the AAR request toward PCRF when the system has determined that the call contained a URN which matched one of those provisioned in the emergency call profile.
2. Include the SERVICE URN coded as “sos” in the AAR request toward PCRF, when the system has determined that the call is an emergency call, based on the received Called URI, which matched one of the emergency prefixes configured in the emergency profile.