National Security and Emergency Preparedness for SIP
The Oracle® Enterprise Session Border Controller (ESBC) supports Emergency Telecommunications Service (ETS), which gives priority treatment of National Security and Emergency Preparedness (NSEP) communications for IP network infrastructures. ETS can increase the likelihood that calls, sessions, and other communications will be successfully completed when they are initiated by government-authorized users over the public network infrastructure. Legacy circuit-switched services such as Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS) also fall under the ETS rubric, and are now also supported on the ESBC.
To provide this support, you can enable the ESBC to act on SIP calls that contain an ETS dial number (DN) and/or the SIP Resource-Priority header that carries ETS resource values.
The ESBC identifies ETS calls by using the system’s network management controls (NMC) functionality. With NMC and Resource-Priority header (RPH) support enabled on your system, the ESBC detects ETS calls and provides the appropriate treatment for them.
The ESBC supports this feature by treating ETS calls based on the r-value parameter in the Resource-Priority header. The r-value is a key piece of information because it defines the resource priority that the call originator requests. The r-value parameter provides namespaces and priorities that the ESBC can manipulate in outgoing traffic.
The system also allows you to specify a percentage of total session capacity that you reserve for NSEP sessions. When you do this, you extend upon the system's prioritization of NSEP sessions by ensuring transport of emergency sessions even when the system is overloaded with standard traffic. The system provides checks on what you can reserve and reports on its use of this reservation behavior.
An RPH profile is applied to an NMC rule to specify r-values, a media policy to use, and what type of call treatment to apply. Although this also applies to an NMC rule, the RPH policy provides information about which r-values to insert and which to override.
Matching by NMC and by RPH
When a Oracle® Enterprise Session Border Controller has been enabled to act on RPH, it checks incoming requests for RPH, tries to parse that RPH, and then rejects requests in the circumstances listed below. For all of these rejections, the Oracle® Enterprise Session Border Controller logs the error at the TRACE level.
- Request with multiple instances of the same namespace in the RPH—The Oracle® Enterprise Session Border Controller sends out a 400 Bad Request response with the Invalid RPH - Namespace repeated header showing that there are multiple instances of the same namespace in the RPH.
- Request with invalid resource priority for a namespace—The Oracle® Enterprise Session Border Controller sends out a 400 Bad Request response with the Invalid RPH - Invalid rvalue: x showing that there is an invalid resource value (where x is the invalid value).
- Request with WPS namespace, but without ETS namespace—The Oracle® Enterprise Session Border Controller sends out a 400 Bad Request response with the Invalid RPH - No ETS value header showing that there is no ETS namespace.
If the Oracle® Enterprise Session Border Controller successfully parses the RPH, it identifies the ETS call by checking the Request-URI of the incoming request against destination identifiers that you configure in the NMC rules. If there is a match between the request’s ETS DN and the destination value identifier in the NMC rules, the Oracle® Enterprise Session Border Controller tags the call; note that NMC rules need to be configured with the rph-feature parameter set to enabled to identify an ETS call properly. If there is no match to an NMC rule, then the Oracle® Enterprise Session Border Controller performs matching based on RPH by comparing resource values (r-values) in the RPH with values you set in the RPH profile configuration.
For an ETS call that matches by ETS DN and NMC rule, the system checks the NMC rule to determine if it has an RPH profile (with r-values) assigned to it. If so, the Oracle® Enterprise Session Border Controller continues by comparing the RPH profile’s r-values against those in the request’s RPH. In cases where the RPH does not contain a recognized value r-value, the Oracle® Enterprise Session Border Controller:
- Processes the call as it normally would (as a non-ETS call) without changing the RPH if the resource-priority option tag is not present in the Required header (for an INVITE only and not any other requests or response from which RPH would be deleted)
- Rejects the Request when the Require header has the resource-priority header; or, inserts an Accept-Resource-Priority header (ARPH) in the response if the insert-arp-header parameter option is enabled
However, the call goes through the Oracle® Enterprise Session Border Controller as an ETS call when it is matched by ETS DN and the applicable NMC does not have an RPH profile assigned. According to the settings in the NMC rule, the Oracle® Enterprise Session Border Controller either diverts or rejects such a call. And when the call matches by RPH rather than ETS DN, the Oracle® Enterprise Session Border Controller applies the configured RPH profile from the relevant NMC rule.
It can be the case that non-ETS calls have RPH in their requests. Here, the Oracle® Enterprise Session Border Controller call treatment is performed according to the settings in the matching RPH profile when there is no matching NMC rule. When you configure treatment as “reject,” then the Oracle® Enterprise Session Border Controller rejects the call with a 417 Unknown-Resource Priority status code. When you set the treatment to either “accept” or priority, the Oracle® Enterprise Session Border Controller allows the call to proceed as a non-ETS call or as a priority call.
The ETS r-value can appear in ACK, BYE, INFO, PRACK, REFER and UPDATE requests. In cases when it does and the session with which the request is associated is a non-ETS call, the Oracle® Enterprise Session Border Controller removes the RPH from the request before forwarding it and logs a TRACE-level error. The Oracle® Enterprise Session Border Controller also removes RPH from responses before forwarding them and logs a TRACE-level error when responses contain RPH headers with ETS values for non-ETS sessions.
Call Treatment
This section describes how ETS calls are treated as they traverse the Oracle® Enterprise Session Border Controller.
| Call Treatment | Description |
|---|---|
| Routing | ETS calls are routed the same way as any other calls are, except when the applicable NMC rule’s treatment type is divert, and rule defines the next hop. This route takes precedence over other normal routes. |
| Local NMC | ETS calls are exempt from the local NMC, including: session agent constraints, bandwidth constraints (e.g., per-realm bandwidth), per-user CAC, and CPU constraints. However, the call is subject to the ETS congestions control threshold. Licensing session constraints apply. |
| ETS Call Congestion Control | ETS calls are subject to congestion control constraints that you configure specifically for this type of traffic. In the global SIP configuration, you set up one option that defines a load limit (greater than that set for normal calls). |
| ETS CAC | Although the Oracle® Enterprise Session Border Controller uses the call rate control value in the applicable NMC rule, you can also enforce call rate on a per-user basis for ETS calls. |
When the Oracle® Enterprise Session Border Controller receives a SIP INVITE with an RPH matching an NMC with an ETS DN, but whose r-values do not match the NMC’s rph-profile, the Oracle® Enterprise Session Border Controller behaves as follows:
- If the INVITE does not have
the resource-priority option tag and:
- If the matching NMS is set to PRIORITY, the call will be treated as an NSEP call. If there is an rph-profile matching the r-value (not necessarily the one in the NMC), the Oracle® Enterprise Session Border Controller uses the media-policy from that rph-profile for the call. The rph-policy from the NMC (if present) also applies to the call.
- If the matching NMC is not set to PRIORITY, the Oracle® Enterprise Session Border Controller will treat the call as a normal one.
If the INVITE contains the resource-priority option tag, the Oracle® Enterprise Session Border Controller will reject the call with the 417 Unknown Resource-Priority message.
Generating Egress RPH
For each ETS call, the Oracle® Enterprise Session Border Controller generates RPH for the outgoing request. It forms this RPH according to the information in the NMC rule. The outgoing request types are INVITE, ACL, BYE, CANCEL, INFO, PRACK, REFER, and UPDATE.
| Request RPH Status | Generated Egress RPH |
|---|---|
| Incoming request without RPH (matched by ETS DN) | Outgoing RPH value becomes the r-value set in the insert-r-value parameter in the RPH policy applied to the NMC rule. |
| Incoming request without RPH (matched by ETS DN) | If the insert-r-value parameter is empty in the RPH policy applied to the NMC rule or there is no RPH policy applied to the NMC rule, then the egress RPH will also not have RPH. |
| Incoming request has RPH | Egress RPH is the same as the ingress if the
NMC rule has an RPH policy applied but the override-r-value for the policy is
empty or if there is not RPH policy applied to the NMC rule.
If the override-r-value for the policy is set, then the egress RPH is set to that value. |
For example, given an incoming request with the resource priority ets.0, dsn.flash and an RPH policy with an override value of wps.1,ets.1, the egress request would be sent with a resource-priority of wps.1,ets.1,dsn.flash.
The Oracle® Enterprise Session Border Controller also includes RPH in the following series of responses, even when the downstream SIP entity does not respond with an RPH: 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx. The 401 Unauthorized response is an exception.
Media Treatment
If the RPH profile set in an NMC names a media policy, then the Oracle® Enterprise Session Border Controller implements it for the ETS call. This media policy overrides any media policy set in the realm configuration.
The possible Differentiated Services Code Point (DSCP) values for an ETS call are:
- Audio—Applied to the respective media for an ETS call
- Video—Applied to the respective media for an ETS call
- SIP—Applied to the ETS calls’ SIP signaling messages, only for the egress call leg for the ETS session
DSCP Marking for NSEP Traffic
You can configure the ESBC to mark NSEP calls with DSCP codes on a realm-specific basis. To do this, you assign a media-policy that you configure for the realm's NSEP traffic using the nsep-media-policy parameter within the egress realm-config. When the system identifies this traffic, it handles the traffic according to that media-policy, which can include marking the traffic with DSCP values. If you have configure an nsep-media-policy on a realm, the system marks egress SIP messages that belong to NSEP sessions with the TOS bits set by that nsep-media-policy. The system applies this nsep-media-policy to all responses except self-generated responses. The ESBC applies precedence to this policy configuration, referring to other traffic policy configuration if this parameter is empty. Applicable media traffic for this configuration includes ETS and WPS. You can configure this policy using the ACLI, REST, and OCSDM.
The nsep-media-policy configuration provides you with the flexibility to mark NSEP calls going out different realms with different DSCP values. The system uses the same network-management-control and rph-profile configurations to identify NSEP traffic, requiring you to configure these objects normally. In addition. the network-management-control may or may not use an rph-policy in addition to the rph-profile. The use of an rph-policy is dependent on your needs for special r-value handling on this realm's NSEP traffic.
Having identified the traffic, however, the system next checks to see if there is nsep-media-policy configuration on the egress realm. If so, the system uses the media-policy configured under the nsep-media-policy parameter to determine how to handle the traffic.
When the nsep-media-policy is empty, the ESBC refers to the media-policy of the RPH-profile that matches the RPH-header in the incoming SIP message to handle the traffic.
- Refers to the media-policy associated with RPH-profile that matched the RPH header present in incoming SIP message to handle the NSEP traffic.
- If there is no RPH-profile match, the system applies the realm's media-policy to all traffic matching that policy.
- If no media-policy is associated with the rph-profile, then the system refers to the common traffic media-policy configured at egress to handle NSEP traffic.
The ESBC performs this function using the following steps when it receives an NSEP INVITE with an rph-header and the egress realm has a configured nsep-media-policy parameter:
- Check the NMC rule to determine if it has an RPH profile (with r-values) assigned to it.
- If so, the system compares the r-values in the RPH-profile with those in the request’s RPH header.
- If there is a match, and the nsep-media-policy parameter has an assigned media-policy on the egress realm-config, it performs realm-specific DSCP marking.
- The system handles all traffic according to the media-policy, including marking all signaling traffic within the server and client dialogs, as well as the RTP packets for the session with the configured DSCP marking.
Note:
The ESBC does not perform DSCP marking on locally generated responses, including 100 trying and 4xx related to the initial invite, using an nsep-media-policy because it has not yet determined it is handling an NSEP call.Configuration
This feature requires the following configurations:
- Enable the rph-feature in the sip-config.
- Enable the net-management-control in the ingress realm-config.
- Configure an rph-profile to identify and handle NSEP calls based on RPH header match..
- Configure net-management-control rules for treating the NSEP calls properly.
- Enable the rph-feature in those NMCs.
- Associate the applicable configured rph-profile with each NMC.
- Configure a media-policy to mark NSEP calls that match that particular rph-profile with DSCP.
- Associate the configured media-policy to the egress realm by assigning it to the nsep-media-policy parameter in the applicable realm-config.
Note:
Although the applicable rph-profile may have an assigned media-policy, the ESBC ignores that policy when it finds an nsep-media-policy configured on the applicable realm.See Configuring Packet Marking by Media Type and ensuing tasks for instructions on creating a media-policy for media and signaling traffic.
Configure Realm-Specific DSCP Marking for NSEP Traffic
To Configure Realm-Specific DSCP Marking for NSEP Traffic, you enable the rph-feature in the sip-config and enable the net-management-control in the ingress realm-config just as you would to enable handling for all NSEP prioritization.
Procedures for this feature include you configuring an RPH Profile for your applicable NSEP Traffic. See Setting up and Applying an RPH Profile for instruction on how to configure your rph-profile, including identifying and prioritizing this traffic. The RPH profile contains information about how the system should act on the namespace(s) present in a Resource-Priority header. You can associate a media-policy to your rph-profile, but the system ignores that setting when performing this realm-specific function, using the media-policy you configure under the nsep-media-policy parameter instead.
In addition, you:
- Configure a Media Policy for your applicable NSEP Traffic.
- Enable NSEP and Apply the RPH Profile to the NMC.
Note:
You may apply an RPH Policy to the NMC if needed for your implementation. - Associate the media policy to the egress realm under the nsep-media-policy configuration parameter.
Configure a Media Policy for NSEP Traffic
To set up a media policy configuration to mark audio-voice or video packets:
Enable NSEP and Apply the RPH Profile to the NMC
To enable NSEP for an NMC rule:
Reserving Session Capacity for NSEP
You can reserve session capacity for NSEP traffic, which includes WPS traffic, to reserve sessions from the system's total session capacity pool. The ESBC uses this reserved session pool for NESP calls after the general session capacity is utilized. You reserve these sessions by configuring a percentage RPH calls using the reserved-nsep-session-capacity parameter.
The ESBC identifies NSEP calls using the system’s network management controls (NMC) functionality. With NMC and Resource-Priority header (RPH) support enabled on your system, the ESBC detects NSEP calls and provides the appropriate treatment for them. When a SIP INVITE for a call arrives at the ESBC on an ingress realm where network management controls have been enabled, the ESBC checks the NMC rules for a match to the call. If there is none, the call proceeds normally; if there is a match it handles the call according to the rule.
When the ESBC identifies an NSEP call, it normally allocates resources for the call from the general session capacity pool. This pool is shared among all kinds of traffic. When this pool gets exhausted, the ESBC would begin rejecting calls, including high priority NSEP calls.
To avoid dropping NSEP calls because the system is exhausting session capacity, you can configure the reserved-nsep-session-capacity parameter in the system-config element. Your configured value specifies the percentage of the total licensed session capacity that the ESBC reserves for NSEP sessions. The ESBC calculates the number of NSEP reserved sessions from this percentage. By default, this setting is 0%, meaning there are no resources reserved solely for NSEP sessions. When configured to a value over 0%, the ESBC reserves session capacity resources for NSEP traffic.
After this configuration, the ESBC derives its general session pool by simply subtracting the number of NSEP reserved sessions from the total session capacity. The ESBC starts to use this NSEP reserved session pool when it exhausts the general session pool. The ESBC continuously monitors this general session pool. When sessions become available from this pool again, the ESBC moves ongoing NSEP calls from the NSEP-reserved pool to the general pool. This reduces the number of calls being used by the NSEP pool, further ensuring session availability if the general pool becomes exhausted again.
The ESBC rejects your reserved-nsep-session-capacity configuration during the save process if you specify a value that exceeds the percentage capacity of sessions currently available. You can also check this error using verify-config.
When you configure reserved-nsep-session-capacity to a non-zero value, the system also monitors current NSEP traffic and issues alarms and SNMP traps, using critical, major and minor thresholds, to notify you when you are running low on your reserved NSEP session capacity. The default thresholds are 70%, 80% and 90%, equating to minor, major and critical levels of busy NSEP sessions. You can customize these thresholds using the reserved-nsep-sessions sub-element type in the system-config, alarm threshold.
Below is an example of a Reserved NSEP session alarm.
ID Task Severity First Occurred Last Occurred
327684 3068 5 2021-06-18 03:01:25 2021-06-18 03:01:25
Count Description
1 Reserved NSEP session usage (80%) is exceeded threshold of 70%.The system issues these alarms simultaneously with the apSysResrvdNsepSessionCapacity trap within the apSysMgmtGroupTrap group to notify you when session pool usage exceeds these thresholds over SNMP. The system issues the apSysMgmtGroupClearTrap when the reserved session usage falls below this threshold, as documented in the MIB Guide.
Related Configuration
The following configurations, which enable and define network management behavior, are also required for this feature:
- Enable the rph-feature in the sip-config.
- Enable the net-management-control in the ingress realm-config.
- Enable the rph-feature in your target net-management-control.
- Configure an rph-profile to handle NSEP calls containing RPH headers in the session-router.
- Apply your rph-profile to your net-management-control.
Reporting NSEP Reserved Capacity Statistics
The ESBC provides reporting on NSEP reserved capacity using the show sessions command on the ACLI. Reported data includes the number of reserved NSEP sessions and the number of inbound NSEP sessions.
SBC# show sessions
03:21:47-165 Capacity=2000
General Session Capacity=1500
Session Stats -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Total Sessions 0 0 0 0 0 0
SIP Sessions 0 0 0 0 0 0
H.323 Sessions 0 0 0 0 0 0
IWF Stats -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
H.323 to SIP Calls 0 0 0 0 0 0
SIP to H.323 Calls 0 0 0 0 0 0
SIP Audio/Video Stats -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Audio Calls 0 0 0 0 0 0
Video Calls 0 0 0 0 0 0
Messaging Sessions 0 0 0 0 0 0
Reserved NSEP Session Capacity=500
Session Stats ---- Lifetime---
Current Total PerMax
NSEP Inbound Sessions 0 0 0The system also reports on lifetime values of these statistics using SNMP. You can get this information using SNMP queries to the apSysMgmtMIBNSEPStatsObjects MIB, as documented in the MIB Guide.
Reject Non-Emergency Traffic using Emergency DSCP
You can configure the ESBC to reject traffic that uses emergency DSCP codes to designate itself as emergency traffic. This function applies to calls from both registered and unregistered endpoints and for both UDP and TCP traffic.
When configured, the ESBC checks initial INVITE packets to see if it is using any of the DSCP codes you configured in an emergency-dscp-profile to signal an emergency call. When there is a match, the ESBC validates the use of that code by checking whether the INVITE also includes an ETS dial number (DN) and/or the SIP Resource-Priority header (RPH) as a SIP emergency designation. If not, the ESBC drops the INVITE, logs the attempt to improperly use that code, and, if configured, replies to the sender with an error message. You can specify the contents of this message. If you do not configure an error code and text, the ESBC sends the default SIP error code and message “403 unauthorized attempt to use reserved resources”.
To enable this functionality, you configure an emergency-dscp-profile under the session-router branch. These multi-instance profiles include codes you specify for matching and, optionally, error codes/text to send back towards the sender. Parameters include:
- name—Establishes a label for individual emergency-dscp-profiles. You use this label to apply these profiles to session-agents, sip-interfaces or the sip-config. This field supports a maximum of 128 characters.
- tos-values—A space-separated string of decimal or hex numbers, that the ESBC searches for within a packet. If it finds a value configured here, and the packet does not have any SIP information identifying the call as an emergency call, the system rejects the call.
- error-code—This optional field can include an integer that specifies the error code you send back to any endpoint that sends a non-emergency INVITE that includes a DSCP value you configured in this profile.
- error-message—This optional field can include a string that specifies the error text that you send back to any endpoint that sends a non-emergency INVITE that includes a DSCP value you configured in this profile.
You apply these profiles to a session-agent, a sip-interface or the sip-config, by configuring the parameter in those elements, which has the same name as the profile name (emergency-dscp-profile), with the name of the applicable profile. The system using that order as precedence for which profile, if any, applies.
As a prerequisite, you must have also configured the ESBC for NSEP traffic identification and have enabled emergency treatment using NMC rule configuration.
The ESBC uses this feature on initial INVITEs only. If a call fails this check based on the initial INVITE, there would be no further traffic for the call. For any call that proceeds beyond the initial INVITE, the ESBC assumes the call is progressing properly and does not reject messages based on DCSP.
This feature imposes no changes to the system's handling of properly designated emergency calls.
Reporting
When the ESBC rejects a non-emergency call based on this feature, it:
- Increments the “Drop Unauth NSEP DSCP” counter in the show sipd error command.
- Increments your configured error codes, unless they are well known codes, under the “4XX Client Error” statistics in the show sipd invite output.
- Includes debug/trace/error/info level logging in all required log files (log.sipd).
Reporting on NSEP Traffic Statistics
The ESBC provides you with NSEP traffic statistics from the ACLI and SNMP. You can access system wide NSEP traffic reports when you configure the system for applicable network management controls (NMC). In addition, you can configure the system to provide realm-specific reporting on a per-realm basis by configuring the nsep-stats-profile on the session-router and enabling nsep-stats on the applicable realms.
The system-wide NSEP statistics provide global incoming/outgoing success/reject sessions. You can filter your results to a specific or all r-values. Per RFC-4412, the ESBC treats r-value names as case insensitive strings. The ESBC presents these statistics using current window statistics and lifetime statistics:
- In the current window, which uses a duration timeframe of 30
minutes, the ESBC displays:
- Currently active sessions
- The highest number of sessions in the current window
- Total sessions in the current timeframe
- The ESBC categorizes lifetime
statistics using:
- Total sessions
- The highest number recorded among all windows reported
- The highest number of sessions in the lifetime window
The ESBC reports NSEP statistics simultaneously through SNMP. To support this the ESBC uses a set of nested MIB index and value objects that correspond to the ACLI statistics and display.
When you use the ACLI show nsep-stats command without further arguments, the system displays counters on inbound and outbound sessions. You extend this command with the all argument or a specific r-value (namespace and r-priority combination).
The system presents realm-based NSEP statistics using the same timeframe/data scheme presented for system-wide statistics and allows you to filter based on dialed number in addition to r-values:
- Dialed Number Statistics—You configure a set of dialed numbers with a country-code in your nsep-stats-profile. The country code is common for all dialed number, similar to the STD code. Whenever the ESBC processes NSEP traffic, it matches a combination of country-code and dialed number with the req-uri of received/sent messages and increments the corresponding counters with the match results.
- r-values—The system records, increments and displays realm-based r-values in the same manner as it does for system-wide statistics.
Use these show commands with the following arguments to display realm-based NSEP statistics:
- show nsep-stats realms <realm-name>
- show nsep-stats realms <realm-name> <rvalue-name>
- show nsep-stats realms <realm-name> dialed-numbers
You can reset any or all NSEP statistics counters. You reset these statistics to zero using the reset command with same arguments above.
Presentation examples of this reporting is available for the ACLI in the Maintenance and Troubleshooting Guide and for SNMP in the MIB Guide.
Configuring Realm-based NSEP Reporting
For the system to produce realm-level statistics on NSEP traffic, you configure the nsep-stats-profile on the session-router and enable nsep-stats on the applicable realms.
The nsep-stats parameter allows you to specify the realms on which you collect NSEP statistics individually. The system does not collect these NSEP statistics for any realm that has this parameter disabled.
Applicable nsep-stats-profile parameters include:
- state—Enabled/Disabled
- rvalues—Add the r-values on which you want to collect NSEP statistics within realms
- dialed-numbers—Optionally add the dialed number(s) on which you want to collect NSEP statistics for realms.
- feature-code—Add the country STD Code, appended with each configured dialed number. This must be configured if you have configured a dialed-numbers.
If you do not configure the feature-code parameter in conjunction with the dialed-number, the system throws a verify error when you use the done command on your nsep-stats-profile element.
ERROR: feature code must be configured when dialed number is configuredRPH Configuration
This section shows you how to configure RPH profiles and policies that enable the Oracle® Enterprise Session Border Controller to act on SIP calls that have an ETS DN and/or an RPH carrying ETS resources values. There are also settings for the global SIP configuration and for the NMC rule configuration that support this feature.
In addition, note that:
- You must set a media policy for the RPH profile to use. Check your system configuration and note the name of the media policy that best suits your needs.
- Valid values for the parameters that take r-values are wps.x and ets.x, where x is 0 through 4.
Remember to save and activate your configuration after you have completed the processes detailed in this section.
Setting Up and Applying RPH Policy
The RPH policy is a configuration on the Oracle® Enterprise Session Border Controller that you apply to NMC rules. It designates the following for ETS/WPS namespaces:
- An override resource value—Resource value used to override the incoming RPH’s resource value
- An insert resource value—Resource value inserted when the Oracle® Enterprise Session Border Controller does not recognize the RPH, the incoming request has no RPH, or the call is H.323 and matches an NMC rule based on the ETS DN
Note that RPH policies do not apply for DSN, DRSN, Q.735, or any other type of namespace; these remain untouched in outgoing requests.
To configure an RPH policy:
Setting Up and Applying RPH Profile
The RPH profile contains information about how the system should act on the namespace(s) present in a Resource-Priority header (if any). The list of resource values in this configuration calls out the resource values (or r-values) recognizable to the Oracle® Enterprise Session Border Controller; the ETS and WPS namespaces are supported.
You also set a media policy for the RPH profile to use; it defines the Differentiated Services Code Point (DSCP) that the Oracle® Enterprise Session Border Controller uses for media or signaling packets belonging to the egress call leg for the ETS session.
The call treatment parameter tells the Oracle® Enterprise Session Border Controller what to do with a non-ETS call that has RPH in its request; the call can be allowed, rejected, or treated as a priority call.
To configure an RPH profile:
Enabling NSEP for an NMC Rule
In addition to the RPH policy and RPH profile you can set for an NMC rule, you also need to set the state of this feature for the NMC rule.
To enable NSEP for an NMC rule:
Global SIP Configuration Settings Enabling NSEP
For the global SIP configuration, you can turn the NSEP feature on, and you can also set parameters that support call admission and congestion control.
In addition, you can enable the insertion of the ARPH header in a response when the resource-priority tag is present in the Require header and the Oracle® Enterprise Session Border Controller rejects the request with a 417 Unknown Resource-Priority response. The ARPH value is the list of r-values you set in the RPH profile.
To enable NSEP for the global SIP configuration:
Global SIP Configuration Settings Enabling CAC and Congestion Control
To set call admission and congestion control parameters for NSEP:
Setting Up NSEP for Session Agents
In earlier releases, the Oracle® Enterprise Session Border Controller supports NSEP-related CAC for users and for NMC. You can now configure a sessions-per-second rate for session agents. Set in the global SIP configuration, this rate applies to all SIP session agents. When session exceed the limit, the Oracle® Enterprise Session Border Controller rejects them with a 503 Service Unavailable message.
To configure NSEP limits for SIP session agents:
Configure NSEP Resource Reservation
To specify the session capacity to be reserved for NSEP calls, you configure the reserved-nsep-session-capacity parameter in the system-config element. Your configured value specifies the percentage of the total licensed session capacity that the ESBC reserves for NSEP traffic sessions. The ESBC calculates the number of NSEP reserved sessions from this percentage. The default is 0%.
When you configure reserved-nsep-session-capacity to a non-zero value, the system uses default thresholds to trigger minor, major and critical alarms and SNMP traps when session utilization exceeds these thresholds. You can customize these thresholds by configuring the reserved-nsep-sessions alarm threshold type in the system-config.
ORACLE(alarm-threshold)# type reserved-nsep-sessionsTo reserve 15% of total session capacity for NSEP sessions, and customize its minor alarm to trigger at 50% of NSEP sessions: