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® Enterprise 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® Enterprise 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 a Realm

Use the Realm Config element to configure a realm for the Oracle® Enterprise Session Border Controller (ESBC).

  • Configure a physical interface.
  • Configure a network interface.
  • If you use Quality of Service (QoS), confirm that QoS is enabled on the ESBC.

Note:

In Advanced mode, in a table that contains the Realm ID column, you can click a cell in the column to view the realm configuration.
  1. Access the realm-config configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# realm-config
    ORACLE(realm-config)# 
  2. Save the configuration.

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® Enterprise 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:

  1. media-policy—Enter the name (unique identifier) of the media policy you want to apply in the realm. When the Oracle® Enterprise 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.

Interface and Realm Support of DNS Servers

You can configure DNS functionality on a per-network-interface, or per-realm basis. Configuring DNS servers for your realms means that you can have multiple DNS servers in connected networks. In addition, this allows you to specify which DNS server to use for a given realm because the DNS might actually be in a different realm with a different network interface.

This feature is available for SIP only.

To configure realm-specific DNS in the ACLI:

  1. dns-realm—Enter the name of the network interface that is configured for the DNS service you want to apply in this realm. If you do not configure this parameter, then the realm will use the DNS information configured in its associated network interface.

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® Enterprise 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® Enterprise 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® Enterprise Session Border Controller (ESBC) 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 ESBC 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 ESBC 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 ESBC keeps track of these events and provides you with the ability to review these changes.

The preferred values the ESBC 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 ESBC 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 ESBC evaluates SSRC changes when the traffic reaches the egress interface and corrects RTP data before it egresses the ESBC. You may determine that the ESBC 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 ESBC 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 ESBC 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 ESBC supports only up to 7 SSRC changes per SRTP session. Also, if HMU is disabled, the ESBC supports only up to 7 SSRC changes per SRTP session for RTP and RTCP packets.

HMU State Machine

The ESBC implements a state machine to manage HMU behavior that includes 5 states:

  • INIT—For the first packet of a particular stream, The ESBC 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 ESBC keep the state machine in LEARN state. If there is a change, the ESBC 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 ESBC 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 ESBC it can be used for hiding other SSRC values. Also, in the case of a REINVITE, the ESBC may create new flows. In these new flows, the HMU state machine restarts from its INIT state.

HMU Configuration

Use the following procedure to enable hide-media-update on the desired realms. By default hide-media-update is disabled.

  1. In Superuser mode, use the following command sequence to access the realm-config configuration:
    ORACLE# configuration terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# realm-config
    ORACLE(realm-config)# 

    If you are configuring a pre-existing profile, use select to choose the profile you want to edit.

  2. hide-egress-media-update—Set this parameter to enabled to enable HMU functionality on this realm.
    ORACLE(realm-config)# hide-egress-media-update enabled
    
  3. Use done and exit to complete the configuration.

Aggregate Session Constraints Per Realm

You can set session constraints for the Oracle® Enterprise 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:

  1. constraint-name—Enter the name of the constraint you want to use for this realm. You set up in the session-constraints confiuration.

Admission Control Configuration

You can set admission control based on bandwidth for each realm by setting the max-bandwidth parameter for the realm configuration. Details about admission control are covered in this guide’s Admission Control and QoS chapter.