Emergency Registration

The

• Supports registration requests with an emergency registration indication like any other registration request, except that the 
  Unable to show "metadata-from": No such page "_space_variables"
  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 new 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

Call Flow Example of SBC Acting as P-CSCF

Emergency Registration CAC

The 

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

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

Resource-Priority: esnet.1

The

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

Emergency Call Profile

The

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

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.