Lesson 7-Session Border Controller Concepts

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2014, Oracle and/or its affiliatesฺ
S
Session
i Border
B d Controller
C t ll Concepts
C t
ble
fer a
ans
Lesson code: sdcs n - t r
a no
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
o uOracle and/or its affiliates. All rights reserved.
z
ire ense
m lic
to Ra
n
Vie
Lesson Objectives
After completing this lesson, you should be able to:

• Discuss:
– Realms and realm bridging
– Oracle Communications SBC architecture
– Peering (trunking) and Access deployment best current
practices
– Services: signaling, media, routing, and translation
a b le
r
– Session agents and header manipulation sfe n
• Configure: n - tra
n o
– Global SIP parameters and Media Manager s a
) a
hpoolsideฺ
– Realms, SIP interfaces, and steering
m Gu
ฺ c o
ic nt rules, and so on
– Routing policies, header manipulation
i p log tude
@ vo his S
e n to se t
vi © t2014,
(Copyright o uOracle and/or its affiliates. All rights reserved.
z
ire ense
m lic
to Ra
n
Vie
Oracle SBC Configuration and Administration 7 - 2

Lesson Topics
• Topic 1: Realms and Realm Bridging

• Topic 2: SIP Interfaces

• Topic 3: SBC Media Services
• Topic 4: Routing and Translation
• Topic 5: Session Agents
• Topic 6: Header Manipulation Rules e
r a bl
s fe
- t r an
non
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic 1: Realms and Realm Bridging

• Realms Definition
• Realm Bridging Definition e
r a bl
• Deployment Models: s fe
– Peering (SIP trunking) - t r an
non
– Access-Backbone a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

What Is a Realm?
“Ingress Realm” Routing/Interworking “Egress Realm”

Decisions
Re-originated
Request Request Proxy
Signaling and media interfaces, access rules, Signaling and media interfaces, access rules,
security parameters, max sessions and security parameters, max sessions and bandwidth,
bandwidth, number translation, and more… number translation, and more…
A realm:
a b le
• Is a collection of VoIP entities residing in one or more networks s f er
• Typically maps to a service provider
provider, enterprise - t r
enterprise, or end-user
an
population environment. It is defined by a configurationn on element
a sthea environment.
that contains many parameters that applyhto
) i d eฺ
• Is considered as a “Layer 5” definition
ฺ c omandt aG“container”
u of
i c n
resources log de
v oip is Stu
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
A realm Ris a logical definition of a network or a group of networks made up in part by devices
t o
nprovide real-time communication sessions composed of signaling messages and
Vie
that
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.

Realm Bridging
Realm A Routing
Decisions Proxy
Realm C
Realm B
Proxy
Realm D
Realm bridging is the routing of a signaling message coming from a given
a b le
ingress realm to a “next hop” in an egress realm.
s f er
The routing rules (routes, relative cost, and so on) are provided byteither
- r an
“Local-Policy” or “SIP-NAT” configuration elements.
n on
s
Static bridging: Ingress and egress realms are unconditionally a “paired.”
) a
h ideฺ
Example: AC;CA
ฺ c om t G u
Dynamic bridging: Egress realm can be
g i cany, depending
e n on time-of-day,
called number, and so on. iplo tud
vo his S
@
to se t
e n uOracle and/or its affiliates. All rights reserved.
z vi © t2014,
(Copyright o
m ire ense
The goalR
a licCommunications SBC is to bridge realms either statically or
of the Oracle
o When a SIP message is received, the SBC determines what realm it came from.
ent
idynamically.
VKnowing 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 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 (legacy configuration), H.323 stack association, or
l
local
l policy.
li
Dynamic realm bridging is a one-to-many association accomplished by either dynamic local
policy (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.

Before Session Border Controllers
A PSTN
TDM Switch
Service
SIP TDM Channels

Provider
PBX
& PSTN GW
Enterprise
IP Services Provider
or Enterprise
TDM Channels B
PSTN H.323
Service PBX
Provider
TDM Switch
& PSTN GW
ble
fer a
an s
Issues in using
g PSTN services to connect VoIP “islands”:
n - t r
• VoIP-PSTN gateways and the likely need to transcodentwiceo
a
• has ideฺ
Limited number of channels, high cost of ownership
)
• TDM channels are very expensive compared
ฺ c om tot G u
LAN/WAN-equivalent
bandwidth.
l o gic uden
Security and SLA is addressed obyip
the PSTNSt service provider.
@ v his
n t o e t
e
vi © t2014, s
uOracle and/or its affiliates. All rights reserved.
z (Copyright o
m ire ense
R
Traditionally, lic (run by PSTN carriers) have provided the connectivity needed so
a TDM networks
e
that to end users in isolated environments can communicate and service providers can
nVoIP
V i
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.

Eliminating PSTN
SIP
PBX Enterprise or IP
SD Services Provider
Enterprise
IP Network H.323
PBX
le
Using IP networking provides:
f erab
• Simpler and very flexible deployment a n s
n -t r
• Lower cost and less dependency n o
a
s applications
• Better usage of bandwidth and a wealth of
) hanewi d eฺ
ฺ c om tsessions
Using an SBC will add the necessary security, G u and
gic and
resources control, SLA, QoS monitoring, denso on.
o i plo Stu
@ v his
n t o e t
e
vi © t2014, s
z (Copyright o
m ire ense
Ra lic
nto
Vie

Peering Model
Enterprise End users are locally Service Provider

registered here.
SIP
Servers
Registrar
g
Internal
Calls
Trunked calls; no EP
registrations requests e
r a bl
s fe
- t r an
SIP SIPn no
Servers Servers a
) has ideฺ
ฺ c om t G u
Service Provider
g i c e n Service Provider
o i plo Stud
@ v his
n t o e t
e
vi © t2014, s
z (Copyright o
m ire ense
R
The Peering
a model islicgenerally characterized (and there are some exceptions) by the fact that
noe to
nREGISTER requests traverse the SBC.
V i
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

Access-Backbone Model
Realm A: End Users
Realm C: Service Provider
Register SIP
Server
Realm B: End Users Registrar ble
fer a
an s
n - t r
Calls End users are registered a no
registrar. ) has ideฺ
at the service provider’s
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m
amodel islicgenerally characterized by the fact that endpoints send REGISTER
R
The Access
e nto to a registrar that resides in a different realm.
requests
i
V This model is normally configured in an SBC that resides between realms:
Service provider  Served end-user population
Enterprise  Remote worker population

Realm Bridging Models for SIP
SIP
Peering/Trunking Access/Remote Worker
Header Policy-Based Single SIP-NAT

Manipulation Rules Realm Bridging Homed in Access
Realm Bridging (PBRB) Network (SSNHAN)
(HMRRB)
ble
fer a
an s
Open-Access
Open Access
H n
Homed- r
Single SIP-NAT
t
d iin T
Trusted
t d
Internet (OAI)
SIP-NAT Bridge
Network (SSNHTN)
a no
(SNB)
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic configurations. The following aspects, in order of priority, are
abest-practice
R
Models are
e nto when selecting a model:
considered
i
V • e o a ce Minimizing
Performance: g tthe
e use o
of heavier
ea e coconfiguration
gu at o objects, suc
such as S
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
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)

Realm Bridging Models for H.323
H.323
Peering/Trunking Access/Remote Worker
B2BGK B2BGW ble

fer a
ans
Registration-Caching
g g t r
Registration-Proxy
g
n - y
a no
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lictwo architectures for H.323: Peering and Access.
athere are
R
As with SIP,
to
enrecommended
iThe peering configuration is the GW/GW model. Local policy will be used to
Vbridge both realms, resembling the Policy-Based
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.

Creating a Realm Configuration Element
Unique name
Network interface
that will serve this

ACLI Path: media-manager > realm-config realm
training(configure)#
g( g )# media-manager
g
training(media-manager)# realm-config
training(realm-config)# identifier peer
training(realm-config)# network-interfaces M00:0
training(realm-config)# addr-prefix 192.168.0.0/24
bl e
training(realm-config)# done
fer a
realm-config
an s
identifier peer
n - t r
addr-prefix 192.168.0.0/24
a no
has ideฺ
network-interfaces M00:0
... )
If used, requests coming
ฺ c om t Gu
from other subnets will
l o gic uden
be rejected.
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic because (at least initially) the default values of most parameters
CreatingR a realm is simple
e
will to for many configurations. What must be specified are a unique identifier and the
nwork
V i
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).

Configuration Elements View
Realm_a Realm_b Realm_c Realm_d

Realms
net.-int.
net. int. M00:0 net.-int.
net. int. M10:0
Network Interfaces M00:0 M00:100 M10:0
ble
Physical Interfaces M00 M10
fer a
an s
n - t r
a no
The SBC configuration is very flexible: A) realm has idcan eฺ use a
dedicated network-interface or share ฺ c oamnetwork t G u interface with
other realms. l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
to R
Vien

Quiz
A realm is a set of resources and definitions applied to a collection of

VoIP networks.
• True___ False ___
Different IP subnets can be within the same realm.
realm
Realm bridging is based on Layer 3 (IP) decisions.
ble
fer a
an s
p realms can be directly
Multiple y bound to a single
g p physical
y r
interface.
- t
• True___ False ___ n on
a
) h ideinฺ the other
In the peering model, a SIP device must be registered
as
realm. ฺ c om t Gu
o g ic den
• True___ False ___ ip l tu
@ vo his S
e n to se t
vi © t2014,
z
ire ense
m lic
to Ra
n
Vie

Quiz
A realm is a set of resources and definitions applied to a collection of

VoIP networks.
•

True___ False ___
Different IP subnets can be within the same realm.
realm
•

True___ False ___
Realm bridging is based on Layer 3 (IP) decisions.
ble
• True___ False ___  sfer a
p realms can be directly
Multiple y bound to a single
g p physical
y r an
interface.
- t
on
• True___ False ___  a n
as
) h ideinฺ the other
In the peering model, a SIP device must be registered
realm. ฺ c om t Gu
o g ic den
• True___ False ___ ip l vo tu
i s S
@
to se t h
z vi © t2014,
(Copyright o
m ire ense
Ra lic
nto
Vie

Practice
Practice 1: Configuring Peer and Core Realms

ble
fer a
ans
n - t r
a no
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic Summary
• Realms are:
– Networks subject to a predefined set of rules and limitations

– Environments that mapped to business entities (SP,
p
enterprise))
– Isolated from each other
• “Realm bridging” requires deciding what the egress realm
and the next-hop in it will be. b le
f er a
• The main deployment categories are Peering and Access- s
Backbone.
Backbone - t r an
n on
• A realm is bound to a network-interface. sThat
a network-
interface may serve more realms. ) h a ฺ
ide om t Gu
ฺ c
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic 2: SIP Interfaces

• Virtual Signaling Interfaces
ble
fer a
ans
n - t r
a no
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

The sip-config Configuration Element
The sip-config element:

• Must be created in order for the SBC to handle SIP

• Is a global, single-instance, RTC element
Default value
ACLI Path: session-router > sip-config
Default value:
training# show running sip-config The SBC acts ab
le
sip-config s
as a B2BUA. f er
state enabled - t r an
operation-mode dialog n onDefault value:
dialog-transparency enableds a The SBC will
home-realm-id ) a
backbone ฺ
h ide NOT change
egress-realm-id ฺ c om t Gu the call-id
g i c Publice n header field.

nat-mode o i d
pl Stu
o
v his
t o @ e t
e n s
z vi © t2014,
(Copyright o
m ire ense
Ra lic
nto
Vie

SIP Edge Proxy Function and B2BUA
Edge SIPD Edge

Proxy Process Proxy
Function (B2BUA) Function
Media Media
NAT/Relay NAT/Relay
Function Function
bl e
fer a
a n s
The Edge Proxy Function is the SIP protocol stackoand n r
-t makes
the SBC look like a SIP proxy. a n
) h as eฺ
The SIPD is the B2BUA application responsible
c o m Guidfor most of the
SBC’s signaling behavioral features. g i cฺ ent
o i plo Stud
@ v his
n t o e t
e
vi © t2014, s
z (Copyright o
m ire ense
R a lic
to
Vien

SIP Interface
Realm Realm
SIP Signaling SIP Signaling

Messages Messages
The sip-interface:
• Is the SBC’s Edge Proxy Function a b le
s f er
• Receives and transmits SIP signaling massages ran
o n -t
• Provides a service pipe to the SIP daemon (sipd)n
a
) has itransport
• Defines SIP signaling IP addresses, ports,
d eฺ
ฺ c om t policies
protocols, and various SIP processing G u
l o gic uden
A realm can only have one sip-interface.
p t
oi is S
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

sip-interface Key Parameters
ACLI Path: session-router > sip-interface

sip-interface
state Default value enabled Uniquely identifies the
realm-id access1 sip-interface by referring
description to the realm it serves.
sip-port
address 192.168.0.11 Default value: UDP
port 5060 Other values: TCP, TLS
transport-protocol UDP
tls-profile
Multiple sip-port subelements can
allow-anonymous all
be defined in one sip-interface. ble
sip-port
fer a
address 192.168.0.11
an s
port
t
transport-protocol
t t l
5061
TLS n - t r
tls-profile prof1
a no
has ideฺ
allow-anonymous all
...
)
always m Manyuother parameters that
nat-traversal
30 cฺc
o fine t Gtune the sip-interface
nat-interval
i
g ude behavior. n
registration-caching
p loenabled
...
v o is St
i
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

SIP Interfaces realm-id Realm_a realm-id Realm_b

Realm_a Realm_b
Realms
net.-int. M00:0 net.-int. M10:0
Network Interfaces M00:0 M10:0
ble
fer a
ans
n - t r
n o
A sip-interface can be assigned to only one realm!
s a
) ha ideฺ
ฺ c om t Gu
To see a summary of all existing
l o gicsip-interfaces
d e n type:
oshow S tu
ip virtual-interfaces
v
@ e thi s
t o
n © 2014,uOracle
s and/or its affiliates. All rights reserved.
( v i e
Copyright
o
ez nse t
i r
R am lice
i e nto
V

Signaling Packets Path
Admin creates sip-interface and SIP message is parsed,
X86 Host
activates configuration. A lookup processed, rewritten and
table entry is created. Module sent to Traffic Manager.
1 7
Host Section
Media Section
Packet sent to host through a queue. 6
Packet is forwarded
Traffic
to Traffic Manager. 5 Manager* 8 Packet is sent
down to NP.
3
A “key” is built from Transcoding
bl e
source address and DSPs
fer a
port, destination
Lookup an s
address and port,
andd L5 protocol.
t l Network
n - t r
Processor 4
Table* Network
a
Processor
no
) h as eฺ
m Guid
Key is looked up. If no entry is
2 9
A L2 frame is
c o
found or source not permitted,
received; IP
PHY
then packet
g
is
i cฺ ent
discarded.
PHY
Packet
sent out.
plo Stud
packet sent to
NP.
o i
v his
t o @ e t
e n s
z vi © t2014,
(Copyright o
m ire ense
Ra lic
nto
Vie

Quiz
1. Which global element must exist so that the SBC can handle
SIP? _________________________
2. When dialog-transparency is set to disabled, Call-IDs will ____
3. How does the sip-interface
p handle media p packets? ________
4. Which of the following are SIP Interface functions?
a. Sending and receiving SIP signaling _____
b. Re-originating SIP messages _____ e
c. Providing a service pipe to the SIP daemon _____ r a bl
s fe
d. Providing policies for SIP processing _____
- t r an
5. no signaling
How can a specific sip-interface be made to support n
a
has ideฺ
over TCP and UDP at the same time? _____________________
)
6. om
How are a specific realm and a sip-interface ubound together?
ฺc nt G
c
_______________________________________________
i
i p log tude
@ vo his S
e n to se t
vi © t2014,
z
ire ense
m lic
to Ra
n
Vie

Quiz
1. Which global element must exist so that the SBC can handle
sip-config
SIP? _________________________
2. When dialog-transparency is set to disabled,

Call-IDs will ________
change
3
3. How does the sip-interface
sip interface handle media packets? It________doesn
doesn’t! t!
4. Which of the following are SIP Interface functions?
a. Sending and receiving SIP signaling Y
_____
b. Re-originating SIP messages N
_____
a b le
c. Providing a service pipe to the SIP daemon _____ Y s f er
d
d. Providing policies for SIP processing Y
_____ - t r an
5. How can a specific sip-interface be made to support n on
signaling over TCP and UDP at the sameha sa ฺ
time?
_____________________
By creating two sip-ports o m ) u ide
How are a specific realm and i
a c ฺc nt G bound together?
sip-interface
6.
i p log tude
_______________________________________________
o sS
By the realm-id in thevsip-interface
@ e thi
t o
n © 2014,uOracle
( v i e
Copyright
o
ez nse t
i r
m lice
to Ra
n
Vie

Practice
Practice 2: Configuring SIP Interfaces

• Configuring a SIP Interface and a SIP Port for the Peer

Realm
• Configuring a SIP Interface and a SIP Port for the Core
Realm
Tip: Once a sip-interface exists the SBC is potentially able to receive
SIP requests. In order to verify that an INVITE request has been
a b le
received, type: show sipd invite. The general command is fer
a n s
show sipd <method>. t r -
n on
s a
) a
h ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic Summary
• The sip-interface is the SBC’s Edge Proxy Function and it:

– Receives and transmits SIP signaling massages

– Provides a service pipe to the SIP daemon (sipd)
– Defines SIP signaling IP addresses, ports, transport
protocols, and various SIP processing policies
• A realm can only have one sip-interface.
• Incoming IP packets containing SIP messages will be
a b le
discarded unless a sip-interface with a matching IP sfe
r
address and port exists
exists. - t r an
n no
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic 3: SBC Media Services

• Media Proxy Function
• Media Manager and Its Configuration le
a b
• Steering Pool and Its Configuration s f er
• RTP Session
Session-Based t
Based Call Admission Control
- r an
n no
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Media Proxy Function
Edge Edge
SIPD
Proxy Proxy
Application
Function Function
Media Media
NAT/Relay NAT/Relay
Function Function
bl e
fer a
a n s
Provides network address and port translation (NAPT) n r
-t of media
o
n going out to
(RTP) packets coming from the ingress realm aand
the egress realm. ) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
to R
Vien

Media Packets Path
Using information in the steering-pool

X86 Host
configuration, SDP Offer and SDP Answer,
lookup table entries are created. Module

1
Host Section
Media Section
Packet NATed and 5 Traffic
forwarded to other
network processor. Manager*
3
A “key” is built from Transcoding
ble
source address and DSPs
fer a
port, destination
Lookup a n s
address and port,
and L5 protocol Network
Table** n -t r
(expected to be Processor 4 o
Network
n
RTP).
s a
Processor
Key is looked up. If no entry isha eฺ
2 found, the packet is m ) i d 6
A L2 frame is
ฺ c
discarded. Otherwise, othe t Gu Packet
received, IP
packet sent to
PHY
NAPT.lo
g ic data dforen
entry will supply PHY sent out.
NP.
v oip is Stu
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

The media-manager-config Element
The media-manager element:

• Must be created in order for the SBC to handle media
• Is a global, single-instance, RTC element

• Defines media handling state, latching, HNT, timers, traffic
shaping and so on
shaping,
ACLI Path: media-manager > media-manager-config
training(media-manager-config)#show
media-manager Default value
state enabled
ble
latching enabled
fer a
flow-time-limit 86400
n s
Default value. RTP source
initial-guard-timer
subsq-guard-timer
subsq guard timer
300
300
f
from the fi nt -
th first trapacket
IP address will be taken
… …
rather n o from SDP k t
than
RTP
hnt-rtcp disabled
s a
body.
algd-log-level
mbcd-log-level
NOTICE
NOTICE
) a
h ideฺ
om t Gu
… …
media-policing
ic ฺ c
enabled
n
max-untrusted-signaling og 100 de
max-signaling-bandwidth 10000000
l
… …
v oip is Stu
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m liisc where media-related characteristics, such as media latching, timers,
R
The media-manager
to shaping behaviors are configured.
e
and
i ntraffic
V 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.

The steering-pools Configuration Element
Realm Realm
SIP signaling Messages SIP signaling Messages
RTP Traffic RTP Traffic
The steering-pool:
• Is the SBC’s media interface (for a given realm)
• Receives and transmits RTP packets a b le
s f er
• Defines a media IP address and a pool (range) of ports from
- t r an
which
hi h port(s)
t( ) are dynamically
d i ll allocated
ll t d for otnbli h d
f every established
n
session s a
• Provides call admission control (CAC) by ) a
hsetting ea ฺlimit of
i d
sessions going into and out of acrealm
ฺ c om t Gu
o g i d e n
A realm can have more than one l tu
ip steering-pool.
@ vo his S
e n to se t
vi © t2014,
z
ire ense
a m licsets of ports that are used for steering media flows from one realm to
SteeringRpools define
e nto through the SBC. When the SBC is communicating with a device in a specific realm
another,
i
V 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.

How Is Media Steered to the SBC?
Steering Pool: Steering Pool:

192.168.0.11 172.16.0.11
Ports 30000- Ports 20000-

30999 20999
Realm A Realm B
SDP Offer in INVITE
Rewritten SDP Offer
c=IN IP4 192.168.0.101
m=audio 5062 RTP/AVP 0 101 c=IN IP4 172.16.0.11
m=audio 20008 RTP/AVP 0 101
SDP Answer in 200 OK ble

Rewritten SDP Answer
fer a
c=IN IP4 192.168.0.11
c=IN IP4 172.16.0.100
an s
m=audio
m audio 30002 RTP/AVP 0 101
n - t r
m=audio 6540 RTP/AVP 0 101
a no
) h as eฺ
In the rewritten SDP body, the SBC replaces:
c o m Guid
• The original IP address with the i ฺ
csteering n t
pool’s IP address
l o g d e
• The original port with a o ip allocated
port S tu from the pool
v
@ e thi s
t o
n © 2014,uOracle
( v i e
Copyright
o
ez nse t
i r
Media isR
am ice
“steered” tol flow through the SBC rather than directly between the media endpoints.
e
This
i ntisothe way the SBC will control media. In some cases, where we do not wish to control
V 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.

Steering Pool Configuration
A steering-pool must be assigned to every realm in which
media is handled by the SBC (most common case).
ACLI Path: media-manager > steering-pool

training(media-manager)# steering-pool
training(steering pool)#
training(steering-pool)# ip-address
ip address 192.168.0.11
192 168 0 11
training(steering-pool)# start-port 20000
training(steering-pool)# end-port 20999 Media IP address
training(steering-pool)# realm-id peer
training(steering-pool)# done Range of UDP ports
bl e
steering-pool
ip-address 192.168.0.11
fer a
start-port 20000
an s
The realm served by this
end-port
end port 20999 steering-pool
steering pool
n - t r
realm-id peer1
a no
aIf sleft blank,
network-interface
The network-interface used by the
last-modified-by admin@console
) h d e ฺ the steering-
last-modified-date steering-pool.
2009-11-04 m the G
ouses 18:24:41 i
u network-interface
training(steering-pool)# exit pool
ฺ c
c byethen realm. t same
giused
o i p l o
S tud
@ v his
n t o e t
e
vi © t2014, s
z (Copyright o
m ire ense
One canR
a lic than one steering pool for a given realm. For example, in addition to
configure more
e
the to pool shown, above a second steering pool can be created where the realm-id is
nsteering
V i
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, of-course, conform to that
network-interface subnet.

SIP Interfaces realm-id Realm_a realm-id Realm_b

Steering Pools realm-id Realm_a realm-id Realm_b
Realm a
Realm_a Realm b
Realm_b
Realms
net.-int. M00:0 net.-int. M10:0
Network Interfaces M00:0 M10:0

ble
fer a
ans
n - t r
a no
) has ideฺ
A steering pool can only be assigned
ฺ c om to one
t G u
realm.
A realm can have more than lone o gicsteering d e n pool.
v oip is Stu
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic layered configuration diagram includes the elements shown for each
a the basic,
R
At this point,
o
ent Note that the sip-interface and the steering-pool are pictured at the same “level”
irealm.
Vbecause both are directly bound to a specific realm.

Steering Pool–Based Call Admission Control
The steering pool size limits the maximum number of concurrent calls
(incoming + outgoing) in a realm.

A call can “consume” two or four UDP ports.
• Port allocation:
– One for two voice RTP streams
– One for two voice RTCP streams
– One for two video RTP streams
bl e
– One for two video RTCP streams
fer a
• Example: At a given moment, in a specific realm, the active
a n scalls
t r
are: on- n
– 300 voice calls 600 ports allocateds a
– 500 voice/video calls
a
h ideฺ
2000 ports )allocated
– The realm’s steering pool shouldฺ c omat tleast
have G u
2600 ports!
ic n
i p log tude
@ vo his S
e n to se t
vi © t2014,
z
ire ense
m lic pools can provide call admission control based on the number of
a of steering
R
Proper planning
e nto calls. For an environment that mainly supports voice (not video), it can be
concurrent
i
V 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.

Example: Steering Pools and Sessions
Access1
11.120.0.11
RTP
Backbone
RTCP …
172.16.0.11
1000 UDP ports RTP
Steering Pools
SBC Soft-
Switch
11.160.0.11 … RTCP
RTP
5000 UDP ports
RTCP
… ble
fer a
Access2 2000 UDP ports
ans
Assuming all calls are voice and RTCP is used:
n - t r
• Access1 is limited to 500 calls, and Access2 is limited to 1000 calls.
a no
•
has ideฺ
Calls between Access1 and Access2 (assuming they are routed through the soft-switch) will
)
only require 1000 ports in the Backbone steering pool. Each such call consumes TWO
sessions out of the licensed number of sessions.
ฺ c om t Gu
• gic uden
Calls between Access1 or Access2 and the “rest of the world” will require 3000 ports in the
l o
oip is St
Backbone steering pool. Each such call consumes ONE session out of the licensed number
of sessions. v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Quiz
For the SBC to control media, you must create the following
configuration elements:
a. ___________
b. ___________
In order to force the media through the SBC, the SBC will:
a. _______________________________________
Steering pool size should be the same in all realms. le
a b
a. True
s f er
b. False - t r an
n
The total number of ports in all the SBC’s steering pools oisn related to
a
the maximum number of licensed sessions. has eฺ
m ) uid
a. True c o G
g i cฺ ent
b. False lo
oip is Stud
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Quiz
For the SBC to control media, you must create the following
configuration elements:
media-manager
a. ___________
b. ___________
steering-pools
gp
In order to force the media through the SBC, the SBC will:
a. Modify IP addresses and ports in the SDP body
_______________________________________
Steering pool size should be the same in all realms. le
a b
a. True
s f er
b. False - t r an
n
The total number of ports in all the SBC’s steering pools
oisn related to
a
the maximum number of licensed sessions. has eฺ
m ) uid
a. True c o G
g i cฺ ent
b. False lo
oip is Stud
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic Summary
• The SBC media proxy function is responsible for NATing

media between bridged realms.

• The media-manager configuration element defines media-
related characteristics.
• Steering pools are considered media resources by which
the number of concurrent calls in/out of a realm can be
limited (CAC). b le
f er a
• Media is steered (forced) through the SBC by rewriting sthe
SDP body using steering pools’
pools IP addresses and - t r an
allocated ports. n on
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Practice
Practice 3: Configuring Media Services

• Configuring the Media Manager

• Configuring a Steering Pool for the Peer Realm
• Configuring
C fi i a St Steering
i P Pooll ffor th
the C
Core R
Realm
l
ble
fer a
ans
n - t r
a no
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic 4: Routing and Translation

• Essential Terms: Routing, Translation
• Mechanisms Involved e
r a bl
• Local Policies s fe
- t r an
non
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Terminology
Routing is:
a. Identifying a SIP request’s ingress realm,

b. Applying relevant rules, and
c Determining the egress realm and the destination* in it
c.
where the re-originated SIP request will be sent
• Based on information in the SIP message, not Layer 3 info!
Translation is: a b le
s f er
• Changing explicit IP addresses that appear in the tSIP
- r an
message header fields—also called “Topology n
noHiding”
s a
) a
h ideฺ
ฺ c om t Gu
*Also called “next hop” l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
R
nto
Vie

Translation “For Dummies”
Signaling Signaling
Signaling A Message B C Message D Signaling
or Media or Media
Device Device
Media Media
Packet Packet
Translation means: AB becomes CD in the outgoing message/packet.
A, B, C, and D are IP addresses.

ble
Signaling example: INVITE message fer a
– A in Via: and Contact: will be replaced by C. ans
– B iin R
Request-URI
t URI will
ill b
be replaced
l dbby D
D. n - t r
– Performed by the B2BUA (sipd) a no
Media example: RTP packet embedded in UDP/IP
) has ideฺ
– A (src. IP:Port) will be replaced by C (translated
ฺ c omdst. t G u
src. IP:Port).
l o gichardware
– B (dst. IP:Port) will be replaced by D (translated
d e n IP:Port).
oip is Stu
– Performed by the SBC’s media section
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
to R
Vien

Who Does What?
SIPD SIP-NAT* Local-Policy

Basic B2BUA Functionality Configuration Element Configuration Element
Routing No Yes Yes

– Static and limited – Very flexible
Translation Yes Yes No

For Request-URI, Via, For any header
Call-ID, Contact, Route
and Record-route only
a b le
The local policy should be preferred over the SIP-NAT mechanism, s f er
which is older and restrictive. - t r an
n n
oin
Translation required for headers other than those shown a the table
s
ha (discussed
can be achieved using header manipulation rules
) i d eฺ later).
ฺ c om t Gu
l o gic uden
* Explained in a later lesson
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
There are
t o R two key configuration elements that provide routing rules: The most commonly
n Local Policy and the older SIP-NAT. While the SIP-NAT can be still used for routing, it is
Vie
used
recommended to only use it (where necessary) for its translation capabilities.

Local Policy
The Local Policy mechanism provides SIP and H.323

signaling routing based on:

• Ingress realm
• Calling and/or called number pattern
• Route priority (cost and availability time)
• More
a b le
Multiple local policies can be (and typically are) created. er
s f
The Local Policyy configuration
g element contains: - t r an
• Matching criteria n on
s a
a
h ideฺeach of
• Zero or more “policy-attributes” subelements,
)
which defines a “route” ฺ c om t Gu
c gi uden
l o
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic elements can be configured in one local-policy element. Each
R
Several policy-attributes
e nto defines a “route” in terms of the next-hop address in a specific egress realm. A
effectively
i
V 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. Or…
• Looking at the request’s source IP address. Iff that IP address is known as a session-
agent, that session-agent belongs to the ingress realm looked for. If that doesn’t work
then…
• Looking at the request’s destination IP address. This IP address is the sip-interface that
serves the ingress realm.

The Local Policy Configuration Element
ACLI Path: session-router > local-policy
local-policy Matched against number in the From:
from-address *
to-address 212 617 Matched against number in the Rq-URI
source-realm access1
activate-time N/A This local policy will be looked at when
deactivate-time N/A a request comes from this realm.
state enabled
policy-priority none
policy-attribute Possible destinations for
next-hop 122.22.22.22 the re-originated request
realm backbone
a b le
Times this routeer
...
Route start-time 0000
n
is available s f
tra
end-time 2400
days of week
days-of-week M-F
M F
n -
cost 0
a nohave different
If all routes
app-protocol SIP
a sbe that
costs, with the lowest
policy-attribute
10.3.0.142 m)
h will
i d eฺ
taken.
Route
next-hop
ฺ c o t Gu
realm
nonegi
alpha-tel
c e n
action
l o d
...
v oip is Stu
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic of matching criteria and zero or more policy attributes. The matching
The localRpolicy consists
e ntoinclude:
criteria
i
V • Ca g add
Calling address/number/domain/domain
ess/ u be /do a /do a names
a es
• 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
Add
• H323 CallingPartyAddress (From) H323 CalledPartyAddress (To)
• * (wild card)

policy-attributes Configuration
Zero or more policy attributes may be configured as subelements of the local-policy element.
Policy attributes specify next-hop selection criteria and characteristics, such as:
• start-time: The time of day the policy attributes are considered for preference
determination
• end-time: The time of day the policy attributes cease to be considered for preference
determination
• days-of-week: The combination of days of the week plus holidays that policy attributes
can be considered for preference determination
• realm: The realm of the next hop (that is, is egress realm)
realm). If traffic is routed using the
local policy, and the selected route entry identifies an egress realm, then this realm field
value will take precedence over SIP-NAT.
• next-hop: The next signaling host IP address, fully qualified domain name, session-
agent’s host name, SAG:<session agent group name>, LRT:<local routing table name>, ble
or ENUM:<ENUM server> fer a
ans
• app-protocol:
pp p The signaling
g gpprotocol used when sending g messages
n t r
g to the configured
- g
a no
next-hop. When the SBC receives an ingress signaling message and uses local policy
to determine the message’s destination, it will interwork the signaling between protocols
has ideฺ
(H.323<->SIP or SIP<->H.323) if the signaling type does not match the value configured
)
ฺ c om t Gu
in the app-protocol field. The value is H323 or SIP.
l o gic uden
• cost: The cost configured for local policy to rank policy attributes. This field represents
oip is St
the cost of a route relative to other routes reaching the same destination address. The
v
default value is 0
0.
n t o@ se th
( v ie to u
i r ez nse
m lice
to Ra
n
Vie

Routing Decision
Assuming that an INVITE is received from an ingress realm for which

several local policies are configured, the SBC:

a. Determines the ingress realm (always possible!)
b.
b Looks
oo s a
at a
all LPs
s configured
co gu ed foro thee ingress
g ess realm
ea
c. Ignores LPs that have no match to "From" and "To"
d. Looks at all routes available at this time, in all remaining LPs
e. Then selects the route (using this precedence): e
1. With the lowest cost r a bl
s fe
2. Matching media codec
- t r an
3 In
3. I the
h LP with
i h most specific
ifi To
T address
dd match
h
non
4. In the LP with the most specific From address match a
5. With the narrowest day in the week range ) h
as eฺ
c o m Guid
6. With the narrowest time of the day range
g i cฺ ent
7. First configured in the LP thatlo
o i p has From/To
S tud set to *
@ v his
n t o e t
e
vi © t2014, s
z (Copyright o
m ire ense
Ra lic
nto
Vie

Quiz: Which route will be selected?
Time: Sunday 17:50
a: 2123756814 calls 6175271934 local-policy
from-address *
b: 2123756814 calls 9783456000
to-address 61752
local-policy source-realm happy_com
from-address * policy-attribute
to-address 212 617 next-hop 4.4.4.4
source-realm happy_com realm rrr4
start-time 0000
policy-attribute
next-hop
p 1.1.1.1 end-time 2400 4
realm rrr1 days-of-week U-S
start-time 0000 cost 3
1
end-time 2400 policy-attribute
days-of-week M-F next-hop 5.5.5.5
cost 1 realm rrr5
start-time 1600
5 e
bl
policy-attribute
end-time 1800
next-hop
realm
2.2.2.2
rrr2 days-of-week U-S
fer a
start-time 0000
2
cost 3
ans
end-time
days-of-week
y
2400
U-S local-policy
n - t r
no
cost 3 from-address *
policy-attribute to-address
a
*
as eฺ
next-hop 3.3.3.3 source-realm happy_com
realm rrr3
) h
policy-attribute
3 m Guid
start-time 0000 next-hop 6.6.6.6
end-time 2400
c o realm rrr6
days-of-week U-S
g i cฺ ent start-time 0000
6
plo Stud
cost 3 end-time 2400
o i
v his
days-of-week M-F
cost 5
t o @ e t
e n s
z vi © t2014,
(Copyright o
m ire ense
Ra lic
nto
Vie

Quiz: Which route will be selected?
Time: Sunday 17:50
a: 2123756814 calls 6175271934 local-policy
from-address *
b: 2123756814 calls 9783456000
to-address 61752
local-policy source-realm happy_com
from-address * policy-attribute
to-address 212 617 next-hop 4.4.4.4
source-realm happy_com realm rrr4
start-time 0000
policy-attribute
next-hop
p 1.1.1.1 end-time 2400 4
realm rrr1 days-of-week U-S
start-time 0000 cost 3
1
end-time 2400 policy-attribute
days-of-week M-F next-hop 5.5.5.5
cost 1 realm rrr5
start-time 1600
5 e
bl
policy-attribute
end-time 1800
next-hop
realm
2.2.2.2
rrr2 days-of-week U-S
fer a
start-time 0000
2
cost 3
ans
end-time
days-of-week
y
2400
U-S local-policy
n - t r
no
cost 3 from-address *
policy-attribute to-address
a
*
as eฺ
next-hop 3.3.3.3 source-realm happy_com
realm rrr3
) h
policy-attribute
3 m Guid
start-time 0000 next-hop 6.6.6.6
end-time 2400
c o realm rrr6
days-of-week U-S
g i cฺ ent start-time 0000
6
plo Stud
cost 3 end-time 2400
o i
v his
days-of-week M-F
cost 5
t o @ e t
e n s
z vi © t2014,
(Copyright o
m ire ense
Ra lic
nto
Vie

Topic 5: Session Agents

• Definition
• Benefits e
r a bl
• Configuration s fe
- t r an
non
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Session Agent: General
A session agent (SA):

• Is an external signaling entity that the SBC interacts with

• Is known by the SBC through a corresponding
configuration element
• Is viewed by the SBC as a more “privileged” device
Customer’s proxies, gateways, and softswitches are typical
devices that are configured into the SBC as session agents. ble
fer a
ans
n - t r
a no
SIP
Server
SIP
Server ) has ideฺ
e.g. switch
ฺ c om session-agent
e.g. switch
t G u
session-agent
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m
asignalinglicdevice, typically customer’s equipment, can be made known to the SBC
R
An external
to SBC will view it as more “privileged” than other devices. When such a device, known
enthe
iand
Vas 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”).

Benefits of a Session Agent
Once an external device is configured as a session agent:

• The SBC can apply constraints on signaling traffic to/from

that device
• The SBC can apply various translations and header
manipulations to signaling messages to/from that device
• The SBC can reject incoming signaling messages from
other (non-SA) devices (think about security) a b le
• It can be used as a next-hop in local policies s f er
- t r an
• It can be
b grouped d with
ith other
th session i agents n d tto
t iinoorder
n
s a
form a single logical entity (think about aredundancy and
h ฺ
load-balancing)
o m ) u ide
• More i c ฺc nt G
g e
o i plo Stud
@ v his
n t o e t
e
vi © t2014, s
z (Copyright o
m ire ense
Ra lic
nto
Vie

The Session Agent Configuration Element
ACLI Path: session-router > session-agent

session-agent Uniquely identifies this

hostname AlphaSwitch1 session agent
ip-address 192.169.0.101
port 5060
state enabled
app-protocol SIP A session agent is
app-type normally associated with
transport-method UDP a realm (not mandatory).
realm-id peer1
ble
…
fer a
constraints enabled
ans
max-sessions 500
n - t r
max-inbound-sessions 0 When constraints are enabled
a
limits can be applied to these no
has ideฺ
max-outbound-sessions 200
parameters.
max-burst-rate 100
)
max-sustain-rate 50
ฺ c om t Gu
…
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic acts as the unique identifier for the session agent and must be
a parameter
R
The hostname
e nto This parameter can also have a value that is the domain name or the IP address
configured.
i
V 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.

Session Agent Groups
A session agent group (SAG) is a single logical element that

refers to a group of functionally equivalent session agents.

• Individual constraints might differ for session agents in the
g p
group.
Commonly used for load balancing, a session agent group can
function as a (single logical) next-hop.
• That way, traffic sent to this next hop can be load- a b le
balanced and never sent to a group member that is down. s f er
- t r an
• The load-balancing
load balancing scheme can be set to: on
– a
Hunt (first SA listed in the group that is responsive)
n
a s
h ideฺ
– Round-robin )
ฺ c om t Gu
– Least-loaded
l o gic uden
– More oip v his St
t o @ e t
e n s
z vi © t2014,
(Copyright o
m ire ense
a ic
A SAG isRa group oflsession agents. SAG members are logically equivalent and can be used
e nto
interchangeably.
i This allows for creation of constructs like hunt groups for application servers
V 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.

The session-group Configuration Element
ACLI Path: session-router > session-group Uniquely identifies this

session-group session agent group
group-name AlphaSwitches
p
description Redundant Hunt
Load balancing scheme
Load-balancing
state enabled
app-protocol SIP Values are:
strategy hunt hunt, roundrobin, leastbusy,
propdist, lowsusrate
dest
bl e
AlphaSwitch1
fer a
AlphaSwitch2 Session group members
an s
AlphaSwitch3
n - t r
trunk-group
a no
has ideฺ
sag-recursion disabled
stop-sag-recurse 401,407
)
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic the session agent allocation options for the session-group
a field identifies
R
The strategy
e nto Strategies are used to select the session agents that will be made available by this
element.
i
V 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.

Topic Summary
Session agents are devices treated by the SBC as more

privileged.
Once configured, several mechanisms can be associated with
them,, such as access rules,, header manipulation
p rule-sets,, and
traffic rate constraints.
Session agents can be grouped into one logical entity. This is
the basis for redundancy and load-balancing, which the SBC b le
r a
can apply for traffic that goes to that group. sfe n
n - tra
on
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Topic 6: Header Manipulation Rules (HMRs)

• The sip-manipulation Element in General
• Header rules le
a b
• Element Rules s f er
• Examples - t r an
n no
a
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Header Manipulation Rules: General
• The header manipulation rules (HMR) mechanism is an

extremely powerful tool by which anything, in any header*,

can be manipulated!
• HMRs are based on the “sip-manipulation”
p p configuration
g
element, also referred to as a “rule set.”
• A rule set contains “header rules”; a header rule may
contain “element rules.” ble
– A header rule “works” on an entire header. fer a
a n s
– An element rule “works”
works on items within a specific t r
n-header
header.
a no
) has ideฺ
ฺ c om t Gu
* Including Request-URI, Status-line, o ic SDP
gand d e n
body!
l
v oip is Stu
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic
R
nto
Vie

The sip-manipulation Configuration Element
ACLI Path: session-router > sip-manipulation

sip-manipulation
name my-IP-nat Must be unique in the SBC

description NATing the To header
header-rule
name my_to_1
Must be unique within the
header-name To sip-manipulation element
action manipulate
msg-type request
new-value
element-rule Must be unique within the
name er_1
parameter-name header rule
type uri-host
ble
match-val-type
new-value
ip
$REMOTE_IP The new-value can be either a fixed
fer a
element-rule
an s
value (for example, 172.16.0.100) or
name er_2
n - t r
a value provided by the SBC through
a system variable (very powerful!)
powerful!).
no
parameter-name
type uri-user
a
has ideฺ
…
header-rule
)
name my_to_2
ฺ c om t Gu
gic uden
header-name To
action manipulate
l o
oip is St
…
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m licconfiguration element is the object also known as an “HMR” or a “rule
R
The sip-manipulation
e ntItocan contain one or more (or many) uniquely named header-rules, which are
set.”
i
V 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.

Where Are HMRs Performed?
When properly applied, a rule-set acts on SIP messages that

go through:
• A session agent, or
• A realm
realm, or
• A sip-interface
A rule-set can be applied so it affects either inbound or
outbound traffic, or both. ble
fer a
SIP MSG.
H/W & S/W
SIP Message
ans
Checks
Processing
g
n - t r
& Rewriting
a no
HMR
) has ideฺ HMR
c o m Gu
in-manipulation ic ฺ n t out-manipulation
Caution: Likelyl o g
to affect d e
oip is Stu
routingvdecisions!!!
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m
ahas beenlicwritten (and hopefully tested and verified), it has to be applied. A rule
R
Once a rule
toapplied to traffic as it enters the SBC or just before it exits it. Either way, the rule can
e
can
i nbe
V 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.

Header Rule Parameters and Logic
A header rule functions on the entire header:
• Creating a new header.
• Deleting an existing header.

• Changing the value of a header
header-rule
name What do we want to do with this
header-name header? Add, delete, store, le
a b
action manipulate, none? fer s
comparison-type
- t r an
msg type
msg-type Iff used,
d the
h action
n n
o willll only
l
methods be taken upon
s a a match.
match-value
) ha ideฺ
new-value Used toฺreplace c om tthe G uheader value upon
a match
l o gic orudtoedefine n the header value
v oipwhenisaSnew t header is added
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m licSpecifies the header to which this rule applies. In addition to To, From,
R
• header-name:
i e ntoContact, and so on, you can use request-uri and @status-line.
V • action: As shown. In the case of manipulate,
p , 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.

Header Rule Examples
sip-manipulation
name Remove-header-ex
description
header-rule
name remove_route Removing a header
header-name Route
action delete
msg-type request
new-value
ble
sip-manipulation fer a
name Adding-headers-ex ans
d
description
i ti n - t r
header-rule
a no
Adding a header name
) has ideฺ
add_subject
om t Gu
header-name Subject
ฺ c
action add
l o gic uden msg-type request
v oip is St new-value “some text”
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Element Rule Logic
An element rule functions on a specific item that can be:

• A parameter Example: ;tag=b5gcc7edf
• A non-parameter item Example: +6175279876

header-rule
…
action manipulate
…
element-rule
a b le
name
s f er
parameter-name
- t r an
type
n o n
action
s a
match-val-type What do we ) a ฺ with this
hwantidtoedo
comparison-type element?
ฺ c om Add,
t G u
replace, delete-
match-value i c n
gelement,edelete-header, store?
new-value iplo tud
vo his S
@
to se t
z vi © t2014,
(Copyright o
m ire ense
R a of the
The parameters licsubelement are:
e to
•n name: Uniquely identifies this element-rule
V i
• 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
• val type: Specifies the type of value to be matched (IP address)
match-val-type:
match
• 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.

Referencing Elements in a Header
Parameters in a header have the form ;<name>=<value>.

• Referenced by name
Other items have various forms.
• Easily referenced by predefined “types”
types
ble
fer a
uri-
header-
uri-
display
uri-user uri-host uri-
port
header-
param-name
ans
name
n - t r
a no
h a s header-param
ฺ
) i d e
header-value
ฺ c om t Gu
l o gic uden
uri-header
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic uri-user), you can point precisely to the element that your element
a (for example,
R
Using a type
to act on.
e
rule
i nwill
V In the slide’s
slide s example, tag=g5bcc76
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
header param name
New-value Tag3

Example: The Need for an Element Rule
• If the “To:” and/or the “From:” headers contain an explicit IP
address, you need a general HMR with element rules that will
change it, without changing anything else.

• The item to be changed is referenced by the “uri-host” type.
• The SBC holds the relevant replacement values in specific
system
t variables.
i bl
A B
INVITE INVITE
… …
To: 6175279876@192.168.0.11 To: 6175279876@172.16.0.100 ble
From: “John”<6174120571@192.168.0.101> From: “John”<6174120571@172.16.0.11>
fer a
… …
an s
n - t r
HMR SIP
Device
a no
has ideฺ
sip-interface sip-interface
192.168.0.101 192.168.0.11 172.16.0.11
) 172.16.0.100
Manipulate the "To" and "From" headers in all om Gu
requests such that the uri-host, if it is in the form C cฺcValue is int the
(next hop)
of an IP address, will be replaced by the proper

o g i $LOCAL_IPd e n Value is in the
l $REMOTE_IP
value.
v oip is Stusystem variable. system variable.
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m
a is for alicHMR that is almost always used.
R
This example
to
i e
(A) nshows an incoming INVITE where the From: and the To: headers have explicit IP
V 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.

Example: The Solution
• Addresses the “To:” and “From:” headers topology-hiding issues

• Built into the SBC code; only needs to be applied

sip-manipulation
name NAT_IP
“Manipulate the “To” header in all

description
header-rule
name
h d
header-name
my_To
T
To requests such that …
action manipulate
msg-type request
new-value …the uri-host, if it is in the form of an
IP address, will be
element-rule
name To1
replaced by the proper value. e

parameter-name
type
action
uri-host
replace
r a bl
match-val-type ip
s fe
an
new-value $REMOTE_IP
header-rule
name my_From
n - t r
no
header-name From
action manipulate
msg-type request
a
has ideฺ
new-value
)
element-rule
om t Gu
name From1
parameter-name
ฺ c
gic uden
type uri-host
action replace
match-val-type ip
l o
oip is St
new-value $LOCAL_IP
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
a m lic to exactly fulfill our example requirements.
The HMR Rshown is written
o easily see how the values in the HMR correspond to what we wanted to achieve.
e
You
i ntcan
V

Applying Rule Sets
For an existing rule-set to function, it must be “applied” to:

– A session-agent and/or Highest precedence

– A realm and/or
– A sip-interface
Doing so also determines whether the rule-set will act upon
incoming or outgoing SIP traffic.
Example: Applying a rule-set to e
the peer1 realm r a bl
realm-config
s fe
an
identifier peer1
description
n - t r
addr-prefix
network-interfaces
0.0.0.0
M00:0 no
A rule-set to manipulate SIP traffic
a
has ideฺ
incoming from this realm
…
)
omA rule-set
in-manipulationid
c G uto manipulate SIP traffic
out-manipulationid NAT_IP
ฺ t
…
l o gic udeoutgoing n to this realm
p
oi is S t
v
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m ic is applied to the realm in the out-manipulationid parameter of the
a rule lset
R
The configured
e nto
realm-config
i element. SIP manipulations may be applied incoming (before realm bridging has
V 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.

Quiz
After changing a parameter in an element-rule, you must type “exit”

_____ times before typing “save config.”
When changing the whole value of a header, but not its name, you
should use a ______________ rule.
If you want to set the caller’s name to “Alpha-Tel” on all calls going
out of the SBC, you should:
a. Work on the _________ header a b le
s f er
b. Configure an __________ rule
- t r an
c. The action will be ____________ n on
d. The type we will use to point to the item will s
be
a_________
h a ฺ
o m ) u ide
i c ฺc nt G
i p log tude
@ vo his S
e n to se t
vi © t2014,
z
ire ense
m lic
to Ra
n
Vie

Quiz
After changing a parameter in an element-rule, you must type “exit”

_____
5 times before typing “save config.”
When changing the whole value of a header, but not its name, you
should use a ______________
header rule.
If you want to set the caller’s name to “Alpha-Tel” on all calls going
out of the SBC, you should:
From:
a. Work on the _________ header a b le
s f er
element
b. Configure an __________ rule
- t r an
replace
c. The action will be ____________ n on
s a_________
d. The type we will use to point to the item willabe Uri-display
ฺ
m ) h uide
i c ฺco nt G
i p log tude
@ vo his S
e n to se t
vi © t2014,
z
ire ense
m lic
to Ra
n
Vie

Topic Summary
• The header manipulation rules (HMR) mechanism is a key

feature for interoperability.

• With HMR, any header and any element in a header can
be added,, replaced,
p , or removed.
• Actions can be unconditional or taken on conditions that
can be very simple to very complex.
• Rule sets can be tested by SBC commands before being able
applied. s f er
n tra
n -
a no
) has ideฺ
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Lesson Summary
We have defined and discussed the following major concepts:

• Realms and realm bridging

• Deployment models
• Signaling
Si li iinterfaces
t f
• Media interfaces and call admission control
• Translation (topology hiding) and routing by local policies le
a b
• Session agents
s f er
n
• Header manipulation rules -tra on
a n
a
h ideฺs
)
ฺ c om t Gu
l o gic uden
v oip is St
n t o@ se th
( v ie © t2014,
Copyright
z
ire ense
m lic
to Ra
n
Vie

Vie
n
toRa
i r
( v
m lice
n t
ez nse
ie to u
v
l
o@ se th
o
ฺ
oip is St
c
)
gic uden
om t Gu
a
has ideฺ
n no
- t r an
s
fer a bl
e

Lesson 7-Session Border Controller Concepts

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lesson 7-Session Border Controller Concepts

Загружено:

Авторское право:

Доступные форматы

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2014, Oracle and/or its affiliatesฺ

After completing this lesson, you should be able to:

Oracle SBC Configuration and Administration 7 - 2

• Topic 1: Realms and Realm Bridging

• Topic 2: SIP Interfaces

Oracle SBC Configuration and Administration 7 - 3

Topic 1: Realms and Realm Bridging

Oracle SBC Configuration and Administration 7 - 4

“Ingress Realm” Routing/Interworking “Egress Realm”

Oracle SBC Configuration and Administration 7 - 5

Oracle SBC Configuration and Administration 7 - 6

SIP TDM Channels

Oracle SBC Configuration and Administration 7 - 7

Oracle SBC Configuration and Administration 7 - 8

Enterprise End users are locally Service Provider

Oracle SBC Configuration and Administration 7 - 9

Realm A: End Users

Realm C: Service Provider

Oracle SBC Configuration and Administration 7 - 10

Peering/Trunking Access/Remote Worker

Header Policy-Based Single SIP-NAT

Oracle SBC Configuration and Administration 7 - 11

Peering/Trunking Access/Remote Worker

B2BGK B2BGW ble

Oracle SBC Configuration and Administration 7 - 12

that will serve this

Oracle SBC Configuration and Administration 7 - 13

Realm_a Realm_b Realm_c Realm_d

Network Interfaces M00:0 M00:100 M10:0

Oracle SBC Configuration and Administration 7 - 14

A realm is a set of resources and definitions applied to a collection of

Oracle SBC Configuration and Administration 7 - 15

A realm is a set of resources and definitions applied to a collection of

Oracle SBC Configuration and Administration 7 - 16

Practice 1: Configuring Peer and Core Realms

Oracle SBC Configuration and Administration 7 - 17

– Networks subject to a predefined set of rules and limitations

Oracle SBC Configuration and Administration 7 - 18

Topic 2: SIP Interfaces

Oracle SBC Configuration and Administration 7 - 19

The sip-config element:

• Must be created in order for the SBC to handle SIP

g i c Publice n header field.

Oracle SBC Configuration and Administration 7 - 20

Edge SIPD Edge

Oracle SBC Configuration and Administration 7 - 21

SIP Signaling SIP Signaling

Oracle SBC Configuration and Administration 7 - 22

ACLI Path: session-router > sip-interface

Oracle SBC Configuration and Administration 7 - 23

SIP Interfaces realm-id Realm_a realm-id Realm_b

Network Interfaces M00:0 M10:0

Oracle SBC Configuration and Administration 7 - 24

Oracle SBC Configuration and Administration 7 - 25

Oracle SBC Configuration and Administration 7 - 26

2. When dialog-transparency is set to disabled,

Oracle SBC Configuration and Administration 7 - 27

Practice 2: Configuring SIP Interfaces

• Configuring a SIP Interface and a SIP Port for the Peer

Oracle SBC Configuration and Administration 7 - 28

• The sip-interface is the SBC’s Edge Proxy Function and it:

– Receives and transmits SIP signaling massages

Oracle SBC Configuration and Administration 7 - 29

Topic 3: SBC Media Services