In this section:

Overview

The SBC Core provides SIP Resource Priority Header (RPH) support for non-INVITE Out of Dialog (OOD) messages. When a non-INVITE OOD request (SUBSCRIBE, OPTIONS, PUBLISH, MESSAGE, REFER, NOTIFY) comes with sos urn in request URI or RPH, SBC is enabled to provide enhanced preference and treat such requests as an emergency.

IMPORTANT

The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when 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.

Resource-Priority

A functional entity only includes a Resource-Priority header field in a request or response forwarded to another entity within the trusted domain. If a request or response is forwarded to an entity outside the trusted domain, the functional entity removes the Resource-Priority header field from the forwarded request or response. If a request or response is received from an untrusted entity containing the Resource-Priority header field, the functional entity removes the Resource-Priority header field before forwarding the request or response within the trust domain.

In some deployments, the request for prioritization of a transaction/dialog is marked with the Resource-Priority header field by the UE. For other deployments, the request is identified as a priority request and marked for priority (via a Resource-Priority header field) by a functional entity (e.g., P-CSCF) within the network.

The characteristics of any priority scheme is defined by the namespace used. The namespace determines how priority is applied to the SIP signaling, to the bearer carrying the SIP signaling, and to the bearers carrying any media. Different priority levels exist within each namespace. Priority levels in one namespace have no relationship to the priority levels in any other namespace, i.e. priority level "1" in namespace "A" may have an entirely different level and characteristic of priority treatment to an identically labelled priority level "1" in namespace "B".

A network can support multiple namespaces. It is up to the network operator (potentially based on regulatory or contractual obligations) to define the relationship between the priority mechanisms for each namespace, as well as the call priority levels.

SBC Support for RPH Header

The RPH received in a SIP request is used for rating priority to the request. The RPH received contains r-values, which is a combination of namespace and r-priority and defines the priority associated with the request.

When a message is classified as emergency, the SBC adds a Resource-Priority header field towards the IMS core network where the core network uses the Resource-Priority header field to control the priority of emergency messages.

  • This behavior is governed by provisioning RPH profile associated with egress TG with respect to message direction.
  • RPH header contains the first configured namespace and r-priority value of the RPH profile on the egress TG.
  • If namespace and priority values are not configured, SBC does not add the RPH header field towards the IMS core network.
  • By default, the value of this for namespace and r-priority is not configured on egress TG.
  • This behavior does not apply to mid-dialog requests.

The SBC Core considers all transactions within a dialog as emergency transactions if the Initial dialog request is identified as priority call based on presence of RPH header.

 

This does not require any profile matching logic for mid dialog requests. Also, CAC limitations are NOT applicable to these requests.

 

Classification of Non-INVITE OOD Message as an Emergency Message

The SBC considers the SIP request as emergency only when the Resource-Priority header values included in the request match with the values provisioned as part of RPH profile and are attached to emergency profile.

The SBC considers Non-INVITE OOD requests as emergency requests based on following:

  • Namespace of a received RPH r-value and a configured value exactly match
  • R-priority of the received RPH r-value and the configured value exactly match
  • dialed digits (digits prefix provisioned as part of the emergency profile)
  • sos urn (urn prefix provisioned as part of the emergency profile)

The Namespace and R-priority should match with the RPH profile attached to the ingress trunk group.

Call Admission Control (CAC) for Non-INVITE OOD Messages

Based on the provisioned value of emergency oversubscription factor, priority is given to emergency SUBSCRIBE message in terms of:

  • SUBSCRIBE limit count
  • subscribeRateMax

 Based on the provisioned value of emergency oversubscription factor, priority is given to non-INVITE OOD messages in terms of otherReqRateMax.

This applies to SUBSCRIBE, MESSAGE, OPTIONS, PUBLISH, REFER, and NOTIFY non-INVITE OOD messages.

The SBC supports CAC under zone for other non-INVITE OOD messages. The configurations and mechanism to admit the emergency "other non-INVITE OOD messages" is similar to sipTrunkGroup CAC. 

The SBC also supports End point CAC for Non-INVITE OOD Requests.

Transparency

When the resource-priority option-tag transparency flag is enabled, the resource-priority option-tag is transparently passed, when:

  • ingress REQUIRES header contains resource-priority option-tag and is added in the egress REQUIRES header
  • ingress SUPPORTED header contains resource-priority option-tag and is added in the egress SUPPORTED header

Provisioning and Monitoring

The resource-priority values are configured in emergency profile - RPH profile, and consist of the following two values:

  • Namespace
  • R-priority

When an LSWU is performed to a release which does not offer SIP RPH support for non-INVITE OOD messages, the value of provisioning fields related to this functionality must be set to default.

 

  • No labels