Oracle SBC Configuration and Administration 7 - 2

Oracle SBC Configuration and Administration 7 - 3

Oracle SBC Configuration and Administration 7 - 4
A realm is a logical definition of a network or a group of networks made up in part by devices
that provide real-time communication sessions composed of signaling messages and
potentially media flows. These network devices might be call agents, softswitches, SIP
proxies, H.323 gatekeepers, IP PBXs, and so on that are statically defined by IP addresses.
These network devices might also be IP endpoints: SIP phones, IADs, MAs, media gateways,
and so on that are defined by an IP address prefix.
On the SBC, you configure realms (plus their associated configuration objects) to identify
the interfaces, resources, and policies that apply to the signaling and media going through
them.

Oracle SBC Configuration and Administration 7 - 5

The goal of the Oracle Communications SBC is to bridge realms either statically or
dynamically. When a SIP message is received, the SBC determines what realm it came from.
Knowing that and consulting routing policies (or other routing elements), a decision is made
as to what will be the egress realm and the next hop in it.
It is very important to remember that the SBC bridging decisions are based solely on
information found in the signaling messages—never on Layer 3 information. Layer 3 is always
assumed available and transparent.
Realm bridging may be static or dynamic. Static realm bridging is a one-to-one association
accomplished by using SIP-NAT bridge (now archaic), H.323 stack association, or local
policy.
Dynamic realm bridging is a one-to-many association accomplished by either dynamic local
policy (where resolution to the next signaling hop can be based on time-of-day, day-of-week,
phone number, URI, domain, and so on) or third-party routing/redirect.

Oracle SBC Configuration and Administration 7 - 6

Traditionally, TDM networks (run by PSTN carriers) have provided the connectivity needed so
that VoIP end users in isolated environments can communicate and service providers can
extend their reach to VoIP enterprises and offer services such as IVR, voicemail, and IM.
Using PSTN services and their related issues often made this connectivity expensive and
sometimes infeasible.

Oracle SBC Configuration and Administration 7 - 7

Oracle SBC Configuration and Administration 7 - 8
The Peering model is generally characterized (and there are some exceptions) by the fact that
no REGISTER requests traverse the SBC.
This model is commonly configured in an SBC that resides between realms:
Service provider  Service provider
Service provider  Its point-of-presence
Service provider  Served enterprise

Oracle SBC Configuration and Administration 7 - 9

The Access model is generally characterized by the fact that endpoints send REGISTER
requests to a registrar that resides in a different realm.
This model is normally configured in an SBC that resides between realms:
Service provider  Served end-user population
Enterprise  Remote worker population

Oracle SBC Configuration and Administration 7 - 10

Models are best-practice configurations. The following aspects, in order of priority, are
considered when selecting a model:
• Performance: Minimizing the use of heavier configuration objects, such as SIP-NAT, to
streamline the message flow through the SBC and reduce CPU usage. By eliminating
the use of SIP-NAT, the SBC reclaims some processing power.
• Flexibility: How resilient the configuration is, and how adaptable the configuration is
when turning up new connected networks (for example)
• Scalability: Minimizing redundant configuration objects and setting a template-based
foundation to allow overlay configuration with minimal disruption
• Compatibility: Working with other popular devices in carriers’ VoIP networks
PBRB: Simplest, most versatile, but not always capable of addressing all issues
HMRRB: Most commonly used in peering deployments
SNNHTN: Used in many access deployments if HMRs do not work optimally. Archaic, no
longer in common use
SSNHAN and SNB: Archaic, no longer in common use
OAI: Suitable for some service providers with geographically distributed points of presence
(beyond of the scope of this course)

Oracle SBC Configuration and Administration 7 - 11

As with SIP, there are two architectures for H.323: Peering and Access.
The recommended peering configuration is the GW/GW model. Local policy will be used to
bridge both realms, resembling the Policy-Based Realm Bridging SIP configuration.
For the Access architecture, there are two recommended models: registration caching and
registration proxy.
Registration caching is the most straightforward configuration and is the preferred mode when
handling registrations from IP private branch exchanges (IP PBX). In this mode, the SBC will
aggregate terminal aliases under a single registration request (RRQ) towards the core
gatekeeper (GK).
When you configure the registration proxy feature by setting the q931 and dynamic ports in
the core h323-stack, a unique RRQ is sent to the core GK per endpoint in the access network,
and a different callSignallingAddress port is dynamically allocated for each registering
endpoint. The range of dynamic ports for H.245 connections is also defined.
In this mode, the SBC passes most of the parameters in the RRQ transparently from access
to core.
Registrations are routed to the core according to the associated stack field of the access
h323-stack. This model allows for 1-to-1 or many-to-1 access/core configurations.

Oracle SBC Configuration and Administration 7 - 12

Creating a realm is simple because (at least initially) the default values of most parameters
will work for many configurations. What must be specified are a unique identifier and the
network-interface that the realm will use.
If we want to reject traffic that comes from sources that have specific IP addresses (or IP
address range) we can modify the address prefix, which by default is 0.0.0.0 (and which does
not filter out any traffic). More than one prefix can be defined (not shown in the slide).

Oracle SBC Configuration and Administration 7 - 13

Oracle SBC Configuration and Administration 7 - 14
Oracle SBC Configuration and Administration 7 - 16
Oracle SBC Configuration and Administration 7 - 17
Oracle SBC Configuration and Administration 7 - 18
Oracle SBC Configuration and Administration 7 - 19
Oracle SBC Configuration and Administration 7 - 20
Oracle SBC Configuration and Administration 7 - 21
Oracle SBC Configuration and Administration 7 - 22
Oracle SBC Configuration and Administration 7 - 23
Oracle SBC Configuration and Administration 7 - 24
Oracle SBC Configuration and Administration 7 - 25
Oracle SBC Configuration and Administration 7 - 26
Oracle SBC Configuration and Administration 7 - 27
Oracle SBC Configuration and Administration 7 - 28
Oracle SBC Configuration and Administration 7 - 29
Oracle SBC Configuration and Administration 7 - 30
Oracle SBC Configuration and Administration 7 - 31
Oracle SBC Configuration and Administration 7 - 32
The lookup table contains an entry for each active, unidirectional flow (an ordinary call has
two unidirectional opposing flows). Each entry holds many information items in a binary
format. The ACLI can show, in a readable way, most of the table-entry’s information.
For every RTP (media) packet flowing from left to right, the SBC:
1. Constructs a key by extracting and concatenating the following values from the RTP
packet: source IP address, source port, destination IP address, destination port, protocol,
VLAN ID, incoming slot/port.
2. Looks up the table to find an entry with a matching key. If found –
3. Modifies (on the fly) the packet by replacing the values in step 2 with the “translated”
values taken from the first and second “RES” lines shown.
4. Sends the RTP packet to the destination IP address and port (second “RES” line) through
the egress slot/port and VLAN.

Oracle SBC Configuration and Administration 8 - 33

The media-manager is where media-related characteristics, such as media latching, timers,
and traffic shaping behaviors are configured.
Media latching determines how the SBC reacts to dynamic media flows. When enabled, the
SBC will “lock down” a flow upon receipt of the first RTP packet at an allocated media port.
HNT RTCP determines whether support of RTCP in the SBC is enabled when it performs
hosted NAT traversal.

Oracle SBC Configuration and Administration 7 - 34

A lookup table entry for a unidirectional media flow from left to right is built in the following
steps:
1. An INVITE message with an SDP offer is received at the sip-interface.
2. The SBC creates a lookup table entry with the steering-pool IP address, a port allocated
from the pool and ingress information (slot/port, VLAN ID and protocol)
3. The SBC processes the INVITE, makes the routing decisions, rewrites the SDP body and
enters into the table entry the steering pool address, allocated port and egress information
4. The re-originated INVITE is sent to the next hop
5. A 200 OK with an SDP answer is received
6. The PBX media IP address and port is taken from the SDP answer and written into the
table entry
7. The re-originated 200 OK is sent to the SIP device on the left. Its SDB body contains the
steering-pool IP address and port from step 2
8. The first RTP (media) packet is received
9. The source IP address is copied (latched) from the IP packet into the table entry

Oracle SBC Configuration and Administration 8 - 35

The table entry contains now all the values necessary to construct the outgoing RTP
packet.

Oracle SBC Configuration and Administration 7 - 35

Oracle SBC Configuration and Administration 7 - 36
Steering pools define sets of ports that are used for steering media flows from one realm to
another, through the SBC. When the SBC is communicating with a device in a specific realm
defined by a steering pool, it will use the steering pool’s IP address and a port number (from
the pool of ports) and, through the SDP body, will indicate to the device to send media there.

Oracle SBC Configuration and Administration 7 - 37

Media is “steered” to flow through the SBC rather than directly between the media endpoints.
This is the way the SBC will control media. In some cases, where we do not want to control
the media, the SBC will not rewrite the SDP body and media will flow directly between the
media endpoints. Media is said to be “released” by the SBC.

Oracle SBC Configuration and Administration 7 - 38

One can configure more than one steering pool for a given realm. For example, in addition to
the steering pool shown, above a second steering pool can be created where the realm-id is
also peer1. In the second steering pool, the IP address might be the same but the port range
will be different (and non-overlapping). Another possibility is that in the second steering-pool a
different network-interface will be specified. The ip-address should conform to that network-
interface subnet.

Oracle SBC Configuration and Administration 7 - 39

At this point, the basic, layered configuration diagram includes the elements shown for each
realm. Note that the sip-interface and the steering-pool are pictured at the same “level”
because both are directly bound to a specific realm.

Oracle SBC Configuration and Administration 7 - 40

Proper planning of steering pools can provide call admission control based on the number of
concurrent calls. For an environment that mainly supports voice (not video), it can be
assumed that each established call will take two ports (one for RTP and one for RTCP) out of
the realm’s steering pool, plus two more from the other realm’s steering pool. Thus, the
steering pool can determine the maximum number of concurrent calls going into or out of a
realm.

Oracle SBC Configuration and Administration 7 - 41

Oracle SBC Configuration and Administration 7 - 42
Oracle SBC Configuration and Administration 7 - 44
Oracle SBC Configuration and Administration 7 - 45
Oracle SBC Configuration and Administration 7 - 46
Oracle SBC Configuration and Administration 7 - 47
Oracle SBC Configuration and Administration 7 - 48
Oracle SBC Configuration and Administration 7 - 49
There are two key configuration elements that provide routing rules: The most commonly
used Local Policy and the older SIP-NAT. While the SIP-NAT can be still used for routing, it is
recommended to only use it (where necessary) for its translation capabilities.

Oracle SBC Configuration and Administration 7 - 50

Several policy-attributes elements can be configured in one local-policy element. Each
effectively defines a “route” in terms of the next-hop address in a specific egress realm. A
next-hop address can be set to 0.0.0.0 it the route is used to discard messages coming from
blacklisted numbers.
A local policy created for a specific ingress realm will be looked at whenever a request comes
from a device in that realm. In other words, it is of utmost importance to identify the ingress
realm for each received request. The SBC is always able to determine the ingress realm by:
• Looking through which network-interface the request arrived. If there is only one realm
using that network-interface, then this is the ingress realm.
• Looking at the request’s source IP address. If that IP address is known as a session-
agent, that session-agent belongs to the ingress realm looked for. If that does not work,
then
• Looking at the request’s destination IP address. This IP address is the sip-interface that
serves the ingress realm.

Oracle SBC Configuration and Administration 7 - 51

The local policy consists of matching criteria and zero or more policy attributes. The matching
criteria include:
• Calling address/number/domain/domain names
• Called address/number/domain/domain name
• Source realm
From and To addresses formats can be
• SIP From Address (From), SIP Request URI (To)
• Domain names
• IP Addresses
• H323 CallingPartyAddress (From) H323 CalledPartyAddress (To)
• * (wild card)

Oracle SBC Configuration and Administration 7 - 52

Oracle SBC Configuration and Administration 7 - 54
Oracle SBC Configuration and Administration 7 - 56
Oracle SBC Configuration and Administration 7 - 57
An external signaling device, typically customer’s equipment, can be made known to the SBC
and the SBC will view it as more “privileged” than other devices. When such a device, known
as a session-agent, is configured into the SBC, it is then possible to associate to it several
things such as signaling traffic rate limits and constraints and HMRs.
Session-agents are very often used in local-policies as next-hops. They will be equally likely
to be sources of signaling traffic (“previous hops”).

Oracle SBC Configuration and Administration 7 - 58

Oracle SBC Configuration and Administration 7 - 59
The hostname parameter acts as the unique identifier for the session agent and must be
configured. This parameter can also have a value that is the domain name or the IP address
of a valid next hop, which is a SIP or H.323 signaling element.
The ip-address parameter is the IP address for the session agent if it is identified by a domain
name.
The port parameter represents the UDP/TCP port that the session agent is listening for
signaling.
Session agents may be taken in and out of service by toggling the state field between enabled
and disabled.
The app-protocol parameter specifies the signaling application protocol for the session agent.
The transport-method field identifies what OSI Layer 4 transport protocol is going to be used
in communicating with the session agent.
The realm-id field signals which realm the session agent belongs to. This may be set to *, to
indicate that the session agent may participate in all realms.

Oracle SBC Configuration and Administration 7 - 60

A SAG is a group of session agents. SAG members are logically equivalent and can be used
interchangeably. This allows for creation of constructs like hunt groups for application servers
or gateways.
Session agent groups are defined and allocation strategies are selected to achieve the
desired load balancing. You use the session-group element to construct a session agent
group.

Oracle SBC Configuration and Administration 7 - 61

The strategy field identifies the session agent allocation options for the session-group
element. Strategies are used to select the session agents that will be made available by this
session-group element.
The strategy options include Hunt, RoundRobin, LeastBusy, PropDist, and LowSusRate. By
default, the strategy field value is set to Hunt.
The Hunt strategy selects session agents in the order in which they are listed. For example, if
the first agent is online, working, and has not exceeded any of the defined constraints, then all
traffic is sent to the first agent; if the first agent is offline or if it exceeds any defined constraint,
the second agent is selected and so on.
The Round Robin strategy makes the SBC send traffic to Sas using round-robin algorithm.
The Least Busy strategy selects the session agent that has the fewest number of sessions
relative to the max-outbound-sessions constraint or the max-sessions constraint (that is, the
lowest percent busy) of the session-agent element.
The PropDist (Proportional Distribution) strategy proportionally distributes the traffic among all
of the available session-agent elements according to their relative performance.
The LowSusRate strategy routes traffic to the session agent with the lowest sustained rate of
session initiations/invitations.

Oracle SBC Configuration and Administration 7 - 62

Oracle SBC Configuration and Administration 7 - 63
Oracle SBC Configuration and Administration 7 - 64
Oracle SBC Configuration and Administration 7 - 65
The sip-manipulation configuration element is the object also known as an “HMR” or a “rule
set.” It can contain one or more (or many) uniquely named header-rules, which are
subelements. Each header rule can have none or more (or many) uniquely named element-
rules. An element-rule is a subelement in a header-rule.
The rules are processed in a one-pass sequence. Each rule contains an action that can be
taken unconditionally or conditionally.

Oracle SBC Configuration and Administration 7 - 66

When a rule has been written (and hopefully tested and verified), it has to be applied. A rule
can be applied to traffic as it enters the SBC or just before it exits it. Either way, the rule can
be applied to traffic that goes to (or comes from) a session agent, to traffic that goes to (or
comes from) a specific realm, or to traffic that goes to (or comes from) a sip-interface that
serves a whole group of nested realms.
A SIP message can come from a session agent in a given realm through the realm’s SIP
interface. If there is more than one rule-set possible (for example, one rule-set is applied to
the session agent and another rule-set is applied to the realm), the SBC will select the rule-set
using the precedence: session-agent, realm, sip-interface.

Oracle SBC Configuration and Administration 7 - 67

• header-name: Specifies the header to which this rule applies. In addition to To, From,
Contact, and so on, you can use request-uri and @status-line.
• action: As shown. In the case of manipulate, the real action is defined in a nested
element rule.
• match-value: Indicates the exact value to be matched. The action that you specify is
only taken if the header value matches. The match value can contain a regular
expression when the comparison-type is set to pattern-rule.
• comparison-type: Specifies the comparison type that the match-value uses. The
options are case-sensitive, case-insensitive, pattern-rule, and boolean.
• msg-type: Specifies the message type that the header rule applies to. The value any
indicates both request and response messages.
• methods: Specifies which specific methods the header rule applies to (for example,
INVITE, ACK, CANCEL). Leaving this field blank indicates all methods.

Oracle SBC Configuration and Administration 7 - 68

Oracle SBC Configuration and Administration 7 - 69
The parameters of the subelement are:
• name: Uniquely identifies this element-rule
• parameter-name: Specifies the element (that has the structure of a parameter) to
which the rule applies
• type: Specifies the element (not of a parameter structure) to which the rule applies.
Most types are defined in the next slide.
• action: Specifies the action to be applied to the element
• comparison-type: Specifies the type of comparison to be used
• match-val-type: Specifies the type of value to be matched (IP address)
• match-value: Specifies the value to be matched
• new-value: The new value if the action calls for changing the value of the element in
question. The new value can be any fixed value or a value determined by the SBC via
the use of a system variable.

Oracle SBC Configuration and Administration 7 - 70

Using a type (for example, uri-user), you can point precisely to the element that your element
rule will act on.
In the slide’s example, tag=g5bcc76 is a parameter, because it is preceded by a “;” and
conforms to <name>=<value>. So if you want to act upon the value (g5bcc76), your element
rule will use:
parameter-name tag
New-value h6bcc88
If you want to act upon the name itself (tag), your element rule will use:
Type header-param-name
New-value Tag3

Oracle SBC Configuration and Administration 7 - 71

This example is for a HMR that is almost always used.
(A) shows an incoming INVITE where the From: and the To: headers have explicit IP
addresses, which we want to change.
(B) shows the desired result.
(C) shows what we want our HMR to do. Note the IP addresses at the bottom and how they
relate to those in the INVITEs.

Oracle SBC Configuration and Administration 7 - 72

The HMR shown is written to exactly fulfill our example requirements.
You can easily see how the values in the HMR correspond to what we wanted to achieve.

Oracle SBC Configuration and Administration 7 - 73

The configured rule set is applied to the realm in the out-manipulationid parameter of the
realm-config element. SIP manipulations may be applied incoming (before realm bridging has
occurred) or outgoing (after realm bridging has occurred).
When you apply SIP manipulation rule sets to the incoming traffic in a realm, you may affect
the way SIP messages are translated and routed.
When you apply SIP manipulation rule sets to the outgoing traffic in a realm, the manipulation
is done after realm bridging has occurred. Generally, this means that the manipulation is not
going to affect next hop decisions; rather it is being used to alter SIP header elements in order
to hide topology, like in the example on the slide.
Besides realms, the HMR can also be applied to SIP interfaces or session agents. The SBC
first looks for the HMR in the session agent configuration. If the SBC finds the rule set, it
applies it, if not, it looks for the rule sets in the realm configuration, and then in SIP interface
configuration.

Oracle SBC Configuration and Administration 7 - 74

Oracle SBC Configuration and Administration 7 - 76
Oracle SBC Configuration and Administration 7 - 77
Oracle SBC Configuration and Administration 7 - 78