Realms
Realm configuration is divided into the following functional areas, and the steps for configuring each are set out in this chapter: identity and IP address prefix, realm interfaces, realm service profiles, QoS measurement, QoS marking, address translation profiles, and DNS server configuration.
Before You Configure
Before you configure realms, you want to establish the phy and network interfaces with which the realm will be associated.
- Configure a phy-interface to define the physical characteristics of the signaling line.
- Configure a network-interface to define the network in which this realm is participating and optionally to create VLANs.
If you wish to use QoS, you should also determine if your Oracle Communications Session Border Controller is QoS enabled.
Remember that you will also use this realm in other configurations to accomplish the following:
- Set a signaling port or ports at which the Oracle Communications Session Border Controller listens for signaling messages.
- Configure sessions agents to point to ingress and egress signaling devices located in this realm in order to apply constraint for admission control.
- Configure session agents for defining trusted sources for accepting signaling messages.
Configure realm-config
To access the realm configuration parameters in the ACLI:
Identity and IP Address Prefix
The first parameters you configure for a realm are its name (a unique identifier) and an IP address prefix and subnet mask.
The IP address and subnet mask establish a set of matching criteria for the realm, and distinguishes between realms that you assign to the same network interface.
To configure a realm’s identity and IP address prefix in the ACLI:
Realm Interfaces
The realm points to one network interface on the Oracle Communications Session Border Controller.
Note:
Only one network-interface can be assigned to a single realm-config object, except for Local multi-homing SCTP deployments.To assign interfaces to a realm:
Realm Service Profile
The parameters you configure to establish the realm service profile determine how bandwidth resources are used and how media is treated in relation to the realm. Bandwidth constraints set for realm service profiles support the Oracle Communications Session Border Controller’s admission control feature.
Peer-to-peer media between endpoints can be treated in one of three different ways:
- Media can be directed between sources and destinations within this realm on this specific Oracle Communications Session Border Controller. Media travels through the Oracle Communications Session Border Controller rather than straight between the endpoints.
- Media can be directed through the Oracle Communications Session Border Controller between endpoints that are in different realms, but share the same subnet.
- For SIP only, media can be released between multiple
Oracle Communications Session Border Controllers.
To enable SIP distributed media release, you must set the appropriate parameter in the realm configuration. You must also set the SIP options parameter to media-release with the appropriate header name and header parameter information. This option defines how the Oracle Communications Session Border Controller encodes IPv4 address and port information for media streams described by, for example, SDP.
To configure realm service profile:
- max-bandwidth—Enter the total bandwidth budget in kilobits per second for all flows to/from the realm defined in this element. The default is
0 which allows for unlimited bandwidth. The valid range is:
-
Minimum—0
-
Maximum—4294967295
-
- mm-in-realm—Enable this parameter to treat media within this realm on this
Oracle Communications Session Border Controller. The default is
disabled. Valid values are:
-
enabled | disabled
-
- mm-in-network—Enable this parameter to treat media within realms that have the same subnet mask on this
Oracle Communications Session Border Controller. The default is
enabled. Valid values are:
-
enabled | disabled
-
- msm-release—Enable or disable the inclusion of multi-system (multiple
Oracle Communications Session Border Controllers) media release information in the SIP signaling request sent into the realm identified by this realm-config element. If this field is set to enabled, another
Oracle Communications Session Border Controller is allowed to decode the encoded SIP signaling request message data sent from a SIP endpoint to another SIP endpoint in the same network to resore the original SDP and subsequently allow the media to flow directly between those two SIP endpoints in the same network serviced by multiple
Oracle Communications Session Border Controllers. If this field is disabled, the media and signaling will pass through boht
Oracle Communications Session Border Controllers. Remember that for this feature to work, you must also set the options parameter in the SIP configuration accordingly. The default is
disabled. Valid values are:
-
enabled | disabled
-
QoS Measurement
This chapter provides detailed information about when to configure the qos-enable parameter. If you are not using QoS or a QoS-capable Oracle Communications Session Border Controller, then you can leave this parameter set to disabled (default).
QoS Marking
QoS marking allows you to apply a set of TOS/DiffServ mechanisms that enable you to provide better service for selected networks
You can configure a realm to perform realm-based packet marking by media type, either audio/voice or video.
The realm configuration references a set of media policies that you configure in the media policy configuration. Within these policies, you can establish TOS/DiffServ values that define an individual type (or class) of service, and then apply them on a per-realm basis. In the media profiles, you can also specify:
- One or more audio media types for SIP and/or H.323
- One or more video types for SIP and/or H.323
- Both audio and video media types for SIP and/or H.323
To establish what media policies to use per realm in the ACLI:
- media-policy—Enter the name (unique identifier) of the media policy you want to apply in the realm. When the Oracle Communications Session Border Controller first sets up a SIP or H.323 media session, it identifies the egress realm of each flow and then determines the media-policy element to apply to the flow. This parameter must correspond to a valid name entry in a media policy element. If you leave this parameter empty, then QoS marking for media will not be performed for this realm.
Address Translation Profiles
If you are not using this feature, you can leave the in-translationid and out-translationid parameters blank.
DoS ACL Configuration
If you are not using this functionality, you can leave the parameters at their default values: average-rate-limit, peak-rate-limit, maximum-burst-size, access-control-trust-level, invalid-signal-threshold, and maximum-signal-threshold.
Enabling RTP-RTCP UDP Checksum Generation
The Oracle Communications Session Border Controller can generate a UDP checksum for RTP/ RTCP packets on a per-realm basis. This feature is useful in cases where devices performing network address translation (NAT) do not pass through packets with a zero checksum from the public Internet. These packets do not make it through the NAT, even if they have the correct to and from IP address and UDP port information. The Oracle Communications Session Border Controller calculates a checksum for these packets and thereby enables them to traverse a NAT successfully.
If a checksum is already present when the traffic arrives at the hardware, the system simply relays it.
Hiding Media Updates
The Real-Time Transport Protocol uses timestamps, sequence numbers, and synchronization source (SSRC) endpoint identifiers to identify and maintain media streams between endpoints. Unexpected changes to these can cause some VoIP terminals to drop calls. You can configure the Oracle Communications Session Border Controller (SBC) to Hide Media Update (HMU) changes from endpoints and prevent the associated media flows from failing on a per-realm basis.
The HMU function monitors SSRC, timestamp, and sequence number data within RTP media traffic. The SBC stores this data within the context of individual NAT flows, and manages the flows internally with H.248. Changes to SSRC and sequence number trigger HMU logic. When triggered, the SBC refers to the SSRC, sequence number and timestamp stored in the flow information, calculates the preferred values for all three, calculates a new header checksum, and writes them to the egress media streams. The SBC keeps track of these events and provides you with the ability to review these changes.
The preferred values the SBC writes include:
- The original SSRC
- A new sequence number, calculated from the last sequence number
- A new timestamp, calculated from the new received timestamp and the timestamp delta
When any change to SSRC occurs, the SBC can recognize the issue and, if configured, invoke the HMU logic. Refer to the section on HMU Support for RTP to SRTP Interworking for an explanation about the use of HMU for monitoring sequence numbers.
A common cause for SSRC changes is call transfer. The diagram below depicts a transfer from UE #2 to US #3. The call transfer creates an SSRC change that the administrator has determined may not be accepted by UE #3. By configuring HMU on the egress realm, the administrator prevents these changes from causing the call to fail.
The HMU function operates on traffic at the egress realm. The SBC evaluates SSRC changes when the traffic reaches the egress interface and corrects RTP data before it egresses the SBC. You may determine that the SBC needs to hide media changes from one realm only. If you are not configuring bi-directional HMU monitoring, refer to the following table to understand where to apply your HMU configuration.
Ingress Realm HMU Enabled | Egress Realm HMU Enabled | Result |
---|---|---|
No | No | HMU not used |
No | Yes | HMU applied to response RTP |
Yes | No | HMU not applied to response RTP |
Yes | Yes | HMU applied to response RTP |
Although the feature is RTC, the system only performs HMU on new calls after configuration. In addition, HMU supports HA. The SBC maintains all established calls across a failover. Failover may cause sessions that have HMU active to have a jump in SSRC, timestamps and sequence number. This may trigger the HMU logic and generate RTP data rewrites for flows.
The SBC maintains HMU status messages whenever received RTP packets trigger the HMU logic. You can verify how many HMU transitions have occurred on interfaces using the show media host stats command, and the HMU index per media flow using the show nat by-index command.
Note:
HMU is not supported for RTCP or SRTCP packets. Regardless of HMU configuration, the SBC supports only up to 7 SSRC changes per SRTP session. Also, if HMU is disabled, the SBC supports only up to 7 SSRC changes per SRTP session for RTP and RTCP packets.HMU State Machine
The SBC implements a state machine to manage HMU behavior that includes 5 states:
- INIT—For the first packet of a particular stream, The SBC stores sequence number, SSRC and timestamp in an HMU translation table identified by the index derived from the flow id.
- LEARN—For the next packet of a particular stream, HMU checks if there is change of SSRC. If the SSRC has not changed, the SBC keep the state machine in LEARN state. If there is a change, the SBC changes the state to WAIT.
- WAIT—For the next packet of the stream, HMU check if there is change on SSRC, OR if change in sequence number is not within the permissible limit, it moves the state to TRANS state. It saves the last ingress sequence number and also egress sequence number.
- TRANS—For the next packet of the stream, HMU checks if the changes observed in WAIT state are permanent; in that case it moves the state to HIDE and starts hiding the changed ingress information.
- HIDE—From here onwards, for the RTP packets received, the SBC calculates the sequence number from the latched last egress sequence number before forwarding packets.
Note:
The HMU state machine requires at least two consecutive packets with the same SSRC value before it begins to hide the SSRC value. This ensures that a pattern is set and there is consistency to this SSRC value, which tells the SBC it can be used for hiding other SSRC values. Also, in the case of a REINVITE, the SBC may create new flows. In these new flows, the HMU state machine restarts from its INIT state.Aggregate Session Constraints Per Realm
You can set session constraints for the Oracle Communications Session Border Controller’s global SIP configuration, specified session agents, and specified SIP interfaces. This forces users who have a large group of remote agents to create a large number of session agents and SIP interfaces.
With this feature implemented, however, you can group remote agents into one or more realms on which to apply session constraints.
To enable sessions constraints on a per realm basis:
- constraint-name—Enter the name of the constraint you want to use for this realm. You set up in the session-constraints confiuration.