You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

In this section:

The

Unable to show "metadata-from": No such page "_space_variables"
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 
    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

Unable to show "metadata-from": No such page "_space_variables"
considers this an emergency registration, the "sos" parameter is added in the contact on the egress registration. An emergency registration cannot be deleted. 

The commands "sipRegistrationDeleteByIp" and "sipRegistrationDeleteById" do not work if the registration type is set to "emergency".

Call Flow Example of SBC Acting as P-CSCF

Emergency Registration CAC

The 

Unable to show "metadata-from": No such page "_space_variables"
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.

  • This value is used to increase the registrationLimit on the Trunk Group and Zone by the given percentage  for an emergency registration.
  • If the “emergencyOversubscription” value is greater than zero, 20% of the maximum registration burst size is reserved for emergency registrations. This value is used by the policer on both Trunk Group and Zone.

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

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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.
  • emergencyRegSupported – Emergency registrations are supported, but emergency session establishment is possible without an emergency registration.
  • emergencyRegRequired – Reject emergency session establishment when the session establishment occurs outside of an active emergency registration.

Emergency Session Handling Scenarios

Scenario

Response

"requireRegistration" Setting

Emergency Call Handling Option to Use

Non-emergency request after emergency registration

403 – Forbidden

Required

emergencyRegSupported or emergencyRegRequired

Emergency request after non-emergency registration  

380 – Alternative Service with reason = “Emergency Registration required”

Required

emergencyRegRequired

Emergency request after non-emergency registration failed to route

380 – Alternative Service with reason=”Failure to Route Emergency sessions”

Required-non-priority or none or supported

emergencyRegSupported

Release after failure response to AAR

380 – Alternative Service with reason=”Failure to Route Emergency sessions”

Required-non-priority or none or supported

emergencyRegSupported

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.

  • 480 (Temporarily Unavailable) – by default 18, CPC_DISC_NO_USER_RESPONDING
  • 3xx response – 41, CPC_DISC_TEMPORARY_FAILURE
  • No response received – CPC_DISC_SETUP_REQ_TIMER_EXPIRY

Normal calls do not use a Crankback profile since they route using the stored service route.

 

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

Unable to show "metadata-from": No such page "_space_variables"
includes in the egress message is as follows:

Resource-Priority: esnet.1

The

Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
treats the INVITE as an emergency session establishment. See Emergency Call Profile - CLI for CLI 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

Unable to show "metadata-from": No such page "_space_variables"
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.

 

INVITEConfigured Emergency ProfileSERVICE URN sent to PCRF

R-URI

e.g. sip:999@10.11.12.13

999 Matched

Non-Match

sos

empty

R-URN

e.g. urn:service:sos.police

sos.police Matched

Non-match

sos.police

empty

R-URN

urn:srevice:sos.*

sos Matched

Non-match

sos ("*" omitted)

empty

Any other URI/URNNon-matchempty
  • No labels