DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
The SBC Core acting as a P-CSCF supports the following Emergency-CSCF (E-CSCF) functionality:
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.
"sipRegistrationDeleteByIp"
and "sipRegistrationDeleteById
" do not work if the registration type is set to "emergency"
.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.
registrationLimit
on the Trunk Group and Zone by the given percentage for an emergency registration.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 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.
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 “emergencyCallHandlingMod
e” with the following options:
"380"
message with P-Asserted-Id header and an xml body with <type
> set to “emergenc
y” and <reason
> is set to “Not capable of handling Emergency Sessions”
is sent.
Table 1: Emergency Session Handling Scenarios
Scenario | Response | "requireRegistration" Setting | Emergency Call Handling Option to Use |
---|---|---|---|
Non-emergency request after emergency registration | 403 – Forbidden | Required |
|
Emergency request after non-emergency registration | 380 – Alternative Service with reason = “Emergency Registration required” | Required |
|
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 |
|
Release after failure response to AAR | 380 – Alternative Service with reason=”Failure to Route Emergency sessions” | Required-non-priority or none or supported |
|
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.
Normal calls do not use a Crankback profile since they route using the stored service route.
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>
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.
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:
“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.INVITE | Configured Emergency Profile | SERVICE 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/URN | Non-match | empty |