Overview


High Probability of Completion (HPC) features comprise a set of functionalities that provide an enhanced probability of call completion to authorized Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS) users during network stress and/or congestion.

Note

The use of the GETS SOFTWARE is restricted in the U.S. and U.S. TERRITORIES to NS/EP users authorized by the Office of the Manager, National Communications System (OMNCS).

 The SBC supports the following HPC capabilities:

  • Identification of an HPC call based on the presence of either a GETS-Access Number (AN), or GETS-Number Translation (NT) string.
  • Rejection of a call based on the presence of GET-Feature Code (FC) string.
  • Identification of an HPC call based on the code point in the Calling Party Category (CPC) parameter of the ISUP MIME.
  • Prioritization or rejection of a call based on Resource-Priority Header (RPH) r-values in an initial INVITE. The SBC also processes mid-call RPH.
  • Generation of an RPH for inclusion in egress SIP messages.
  • Support for early or late HPC call classification.
  • Detection and logging of error conditions.
  • HPC Call Admission Controls - ingress CAC for early HPC classified calls, and egress CAC treatment for early and late HPC classified calls.
  • Call Queuing, if an HPC call request fails to get a resource it is queued; when the required resource is available, the processing resumes.
  • Exemption of HPC messages from congestion control.
  • DSCP marking and priority treatment for HPC packets - SIP, Diameter and Media packets.
  • High Priority Media Port Range (HPMPR) - packets received on ports in (HPMPR) are prioritized.
  • Statistics and alarms for monitoring HPC traffic.

There are two methods in HPC call classification:

  • Early HPC classification—An HPC call is recognized based on the received SIP RPH content in the incoming INVITE or the code point in Calling Party's Category (CPC) parameter of the ISUP-MIME. For ANSI, the CPC parameter is National Security/Emergency Preparedness (NS/EP) and for ITU, the CPC parameter isInternationalEmergency Preference Scheme (IEPS).
  • Late HPC classification—An HPC call can also be recognized by the PSX during analysis of the Called Party Number.
Note

The SBC must be configured to use the external PSX for this feature. For more information on using the PSX for GETS / WPS, refer to the PSX document Government Emergency Telecommunications Service.

Caution

Preferential servicing of HPC calls is conditional on the installation of NW-HPC license on the EMS. For more information on EMS licenses, refer to the EMS documentation Licensed Applications and Features.

 The SBC supports the use of different Differentiated Services Code Point (DSCP) marking for signaling traffic that is associated with HPC and non-HPC calls. To support different DSCP marking for HPC and non-HPC calls in a SIP trunk group, the dscpValue parameter in the HPC profile configuration marks HPC calls and the DSCP configuration in the SIP signaling port marks non-HPC calls. The DSCP value configured in the HPC profile takes precedence over the DSCP value configured in the SIP signaling port and applies to all outbound traffic (IPv4 and IPv6) associated with HPC calls.

The outbound SIP signaling messages associated with HPC and non-HPC calls are marked with the DSCP value configured in the SIP signaling port when the hpcCallProfile is not configured in a SIP trunk group.

Caution

Setting the DSCP on the UDP or TCP network socket is a system call, which impacts the system performance if the DSCP frequently switches between HPC and non-HPC calls. 

Note

This feature only applies to HPC calls over UDP transport. This feature does not apply to TCP transport since TCP is byte stream oriented and does not preserve message boundaries.

HPC Call Identification

The SBC provides HPC calls with priority treatment over non-HPC calls during the initial SIP INVITE request processing.

The SBC determines whether a call is an HPC call based on the following:

  • The presence of a Resource-Priority Header (RPH) with either a valid ets.x, or a valid ets.x and wps.y in the initial SIP INVITE.
  • The code point in the Calling Party Category (CPC) parameter of the ISUP MIME. The CPC parameter is National Security/Emergency Preparedness (NS/EP) for ANSI, and International Emergency Preference Scheme (IEPS) for ITU.
  • The presence of either a GETS-Access Number (AN) or a GETS-Number Translation (NT) string in the Request-URI of an initial SIP INVITE.

The SBC accepts the ets and wps namespaces as valid with only the following resource values:

  • for the ets namespace: ets.0 , ets.1, ets.2, ets.3, or ets.4
  • for the wps namespace: wps.0, wps.1, wps.2, wps.3, or wps.4
Note

The SBC uses the multiple value format from RFC 4412 to format an RPH.

Note

This feature does not impact other namespaces that the SBC supports.

The SBC identifies GETS-AN, GETS-NT or GETS-Feature Code (FC) string in the received user string of the Request-URI of an initial SIP INVITE. The received user string refers to the user portion of a SIP:URI with user=phone or the ‘telephone-subscriber’ portion of a TEL:URI (ignoring any visual separators). The SBC allows up to ten GETS-AN, ten GETS-NT, and four GETS-FC strings to be associated with an IP trunk group (TG). For more information on GETS Strings, refer to HPC Call Profile - CLI.

To identify a GETS-FC string in the Request-URI, the SBC performs string matches against provisioned GETS-FC strings (of length [n]). The SBC detects a successful match for a GETS provisioned TG when:

  • the received user string is in the local number format (there is no leading +),
  • the received user string contains at least [n] characters, and
  • the provisioned GETS-FC string matches the leading [n] character of the received user string.

If a GETS-FC string is identified in the initial SIP INVITE Request-URI, the SBC rejects the call with a SIP 403 (Forbidden) response with no RPH.

Note

Processing of the GETS-FC string takes precedence over the GETS-AN and GETS-NT strings.

To identify a GETS-AN or GETS-NT in the Request-URI, the SBC performs string matches against provisioned GETS-AN or GETS-NT strings (of length [m]) respectively. The SBC detects a successful match for a GETS provisioned TG when:

  • the received user string contains at least ten digits, and
  • the provisioned GETS-NT or GETS-AN string matches the first [m] of the last ten digits of the received user string.
Note

DSCP marking for HPC calls

When the dscpValue parameter is modified, the new value applies only to new HPC calls while the existing HPC calls use the previously configured value.

The following call flow illustrates the DSCP marking for HPC calls.

DSCP Marking for HPC Call

 

Note

The SIP 100 Trying provisional response is handled as an exception. The SBC sends this provisional response with a DSCP value that is configured in the SIP signaling port because the provisional response is sent before an incoming call is determined as an HPC or non-HPC call (see the preceding call flow).

The following call flow illustrates the DSCP marking for non-HPC calls.

DSCP Marking for Non-HPC Call

DSCP Marking for T.140 Text Media

In previous releases, the SBC supported Differentiated Services Code Point (DSCP) marking for non-audio streams (video and T.140 text) for both High Priority Calls (HPC) and non-HPC calls. The SBC Core is enhanced to support alternative DSCP marking for T.140 text media stream types from what is used for video and audio media stream types irrespective if the request has an RPH header.

For Government Emergency Telecommunications Service (GETS) / Wireless Priority Service (WPS) calls ( high priority calls), DSCP markings are associated with the provisioned ETS value and in the outgoing message includes an RPH containing the provisioned ETS.x. When the message is destined for the internal network,  there is a single DSCP associated with that ETS value and assigned to all associated signaling and media packets. When it is destined for an external network, there is a single DSCP associated for every peer. In other words, there is a set of DSCP values rather than a single DSCP value in each case, one each for signaling, audio, video and text.

A new parameter "T140 DSCP" is added to QosValues for DSCP marking of T.140 text. The DSCP value for T.140 packets is configured on Packet Service Profile (PSP) basis.

Note

When the parameter "DSCP Passthrough" is enabled, DSCP Pass-through takes precedence over the "T.140 DSCP" setting.

The following figure depicts a T.140 media call.

T.140 Media Call Flow