Acme Packet 4500

Signaled sessions 40,000

Media Sessions 16,000
Transcoded Sessions 7,200
IPSec Tunnels 200,000
Route Table Size 2M
Using the platforms as Session Routers implies that no media is handled; the Ses
sion Router only processes signaling messages.
Call Detail Records (CDRs)
File System Related Commands
Format: Bulds partitions with file-systems on a newly added hard disk dr
ive.
Unmount: Unmounts a partition or the whole hard drive so it can be remov
ed.
Mount: Mounts a newly inserted (or previously unmmounted) formatted hard
disk drive.
show space <partition>: Show available/max space of partition
6100/6300/4600
A conversation or a session is established by exchanging some call control infor
mation (signaling).
Establishing a call means enabling the orderly, controlled, and predictable flow
of "media"
SIP RFC 3261
The SIP (Layer 5,6 and 7):
Provides the signaling plane of a session-based multimedia system
Provides establishment, control, and teardown of session, plus some serv
ices.
Is agnostic to the media type the session uses.
Is used together with other proptocols in order to form a complete commu
nication system:
SDP, RTP, DNS, HTTP, ENUM, RADIUS, DIAMETER.
Is Request-Response model-based.
Message are textual.
Can be user over UDP, TCP or TLS transports.
User Agent (UA)
User Agent Client (UAC)
User Agent Server (UAS)
Basic SIP Entities: Servers
Proxy Server
Provide proxy services and message forwarding.
Registrar
Registrar end-points so they are known in a domain.
Creates location database entries (bindings) of the form: [end-p
oint identity + current IP-address:port]
Back-to-Back User Agent
A device that serves as a termination ppint for calls, processes
them and re-originates them.
Has "Isolation" effect, thus suitable for security and other val
ue added services.
SIP Messages

Structure ASCII-Based, (of both requests and responses):

Star line = "Request Line" or "Status Line" (in responses)
Header = Several lines called "Header Fields"
Body = (Optional)
Session Description Protocol (SDP)
XML information
Instant messaging text
Other data
The start-line in a request contains a request Uniform Resource Identifier (requ
est-URI):
The request URI identifies the address where the request is sent to and
is written in the form of user@host.
The initial request-URI of the message should be set to the value of the
URI in the "To" field.
Several Header fields are normally found in a SIP message:
"Via" header:
Indicates the transport used for the transacion (transaction = r
equest and all its related responses) and identifies the location where the resp
onse(s) to this request should be sent.
The essence of the Via header field is to provide an IP address
and port for responses.
"To" header:
Specifies the desired "logical" recipient of the request, or the
address-of-record of the user or resource that is the target of this request.
Is informational and not used for routing decisions.
"From" header:
Indicates the request initiators logical identity AOR in the form
of user@host.
Is informational and not used for routing decisions.
"Contact" header:
Provides an IP address and port where the device directly receiv
es request. (Location)
"Call-ID":
A string, made as random as possible, that identifies this call.
"CSeq":
An integer and the method itself. This integer increases in each
transaction in the dialog.
INVITE sip:112125555@192.168.0.13:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.0.103:5070;branch=z9hG4bK-1880-1-0
From: sipp <sip:sipp@192.168.0.103:5070>;tag=1
To: sut <sip:service@192.168.0.13:5060>
Call-ID: 1-1880@192.168.0.103
CSeq: 1 INVITE
Contact: sip:sipp@192.168.0.103:5070
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 137
There is usually no "response to a response" but one exeption does exist: This i
s the ACK request that is sent in order to acknowledge the receipt of a successf
ul response (200 OK) to an INVITE (session beginning) request.

SIP Request
Request

Description

INVITE
Indicates that a client is being invited to participate
in a call session
ACK
Confirms that the client has received a final response t
o an INVITE request
BYE
Terminates a call and can be sent by either the
caller o the callee
CANCEL
Cancels any pending request
OPTIONS
Queries the capabilities of servers
REGISTER
Registers the address listed in the To header field with
a SIP server. To and From header fields contain the same AOR.
SIP Responses
--------------------------------------------------------------------Type
|
|
Non-Final
|

1xx Provisional

180 Ringing

Examples

100 Trying
|

183 Session in Progress

|
--------------------------------------------------------------------2xx Success
200 Ok
|
3xx Redirection
302 Moved Tempor
arily
|
Final
4xx Client Failure
403 Forbidden
|
404 Not found

|
5xx Server Failure

nal Error

503 Service Unavailable

504 Server Time-out

|
6xx Global Failure

500 Server Inter

600 Busy Anywher

604 Does Not Exist Anywhere |

--------------------------------------------------------------------Session Description Protocol (RFC 4566): Defines media description
SIP Transaction:
A SIP transaction occurs between a client and a server and comprises all
messages from the first request sent from the client to the server up to a fina
l (non-1xx) response sent form the server to the cliente.
If the request is INVITE and the final response is a non-2xx, the transa

ction also includes an ACK to the response.

The ACK for a 2xx response to an INVITE request is a separate transactio
n.
Dialog:
A dialog is a peer-to-peer relationship between two UAs that persists fo
r some time.
A dialog is established by SIP messages, such as a 2xx response to an IN
VITE request.
A dialog is identified by a call identifier local tag, and a remote tag.
Responses to the INVITE Message
Contain the status line and most header fields that are copied from the request.
The responding device has added the "To:"tag and (optionally) a display string.
The 200 OK also provides the "Contact" information of the called device.
Staless Proxy: Provides the normal forwarding functions but without any events o
r keeping any state information in its memory.
Transaction-Stateful Proxy: Will track and mark all state transitions of a trans
action. Uses "CSeq:" and the branch parameter (in the "Via:") to identify the tr
ansaction it is tracking.
Dialog-Stateful Proxy: Keeps track of the whole dialog. The proxy needs to someh
ow "convince" the two devices to keep working through the proxy for the entire d
ialog. This is how it is done:
The proxy adds a "Record-Route" header field with its own IP address and
port to the request it relays. This tells the receiving device: "Route the next
transactions through me".
This addes header field is copied to the responses and propagates back t
o the initiating device. Now the initiating device too knows that it needs to ro
ute its next transactions through the proxy.
The device that sends the next request will include a "Route:" header fi
eld with the proxy IP address and port and send it out.
B2BUA can perform is translating exlicit IP addresses that appear in the SIP mes
sages. B2BUA changes explicit IP addresses in the request-URI, Via: and Contact:
. Often a device add its own IP to the Call-ID string to improve its uniqueness.
The B2BUA hides that IP address too by generating a brand new Call-ID.
B2BUA re-originated SIP messages, B2B isolates betwenn SIP enviorenments.
Session Border Controllers
Session Border Controllers are session-sware devices that enable control of endto-end, interactive communications across IP network borders.
Session: Any real-time, interactive voice, video, or multimedia communic
ation using IP signaling protocols.
Border: IP-IP network border
Control: Functions spanning security, service reach maximization, SLA as

surance, revenue and profit protection, and regulatory compliance. Interactive s

essions.
SBCs are the source and destination for all signaling messages and media streams
coming into and leaving the providers network.
Session-aware networking is our acrhitectural model for enabling high-quality, e
nd-to-end interactive communications across IP networks.
The SBC provides access-control, signaling constraints, and topology hiding/NPAT
.
The SBC interfaces to multiple networks. To each such network, it presents itsel
f as a proxy for signaling and as a source/destination for media.
SIPD application, which is a B2BUA, is the significant component. It is the term
ination point for an incoming session for which it will originate an outgoing se
ssion toward the final destionation. It will then bridge the two sessions while
blocking information that needs to be blocked, translating information that need
s to be translated, and letting other information items pass unchanged.
Provides signaling proxy functions for SIP, H323, and MGCP/NCS protocols.
Platforms Boot Process
The operation system is a suite of applications, services, and processes that us
e a real-time operating kernel.
Bootloader code -> Inspects the boot parameters (residing in a NVRAM) -> Find ou
t the Image file, and load it to the RAM -> The Kernel starts running and initia
lizes the whole OS envioronment.
Release Naming Conventions
S - SBC, SR, USM (Unified Session manager)
E - ESBC
P - Enterprise Communications Broker
M - Security Gateway
L - Subscriber Aware Load Balancer
C - 4250
Cx - 3810/3820, 4500
Cz - 4500, 4600, 6x00 and virtual machine
D - 9200
4500 - SBC, ESBC, USM, SG, SLB, SR.
Operating System Functions and Services
Media Control: Border gategar funtion, provides the interface bewteen IP
transport domains for session media. Support the following:
Dynamic access control
Topology hiding
Dynamic NAPT/NAT relay
QoS marking
Upstream and dowmnstrem bandwidth policing
Media supervision timers
QoS measurements
DTMF extraction
Lawful intercept (CCC)
Security Front End (SFE): TLS, DoS, Security hardware module (SSM) provi
des dedicated encryption.
Resource and Bandwidth Control: The resource and bandwdth control functi
on is responsible for enforcing bandwidth policies for admission control and con

trolling the opening and closing of media gates for bearer control.
Signaling Services:
SIP B2BUA/IMS P-CSCF/IMS I-BCF
H.323 Gatekeeper and Gateway
SIP-H.323 Inter-working Module
MGCP/NCS b2b virtual gateway and call agent
H.248 b2b virtual media gateway controller and gateway
NAT Relay: The NAT Relay functions provide application-layer gateway (AL
G) services for non-multimedia protocols including TFTP, HTTP, and DNS.
Routing Policy and Accounting: Routing all traffic to a well-known proxy
or routing all trafiic from network A to Network B. Local routing policies work
in conjuntion with DNS and ENYM to determine next-hop routing behavior.
Call admission and routing decisions are based on a wide range of polici
es enabling advanced routing and traffic management capabilities.
Accounting and QoS Reporting: Provides RADIUS CDRs that include accounti
ng information and provides per-session QoS metrics.
show features - Licensed feautures by typing
show version - OS image version by tiping
show version boot - Boot-loader version by typing
ACLI Modes
User mode
Super mode
Configuration mode - bootparam
-

media-manager
security
system
session-router
ntp-sync

prompt-enabled enabled
Up to five simultaneous Telnet/SSH session are supported. Configuration mode can
be entered within only one session at any given time. (Multiple configuration s
ession for training purposes)
Bootparam:
* Boot-related parameters. When changed, a rebbot is required.
* If stored in a NVRAM, no explicit saving is required.
System:
* Elements of a global nature: system parameters, physical interfaces, n
etwork interfaces, and so on.
Media-manager:
* Media-related elements: media-manager, realm-config, steering-pools, a
nd so on.
Session-router:
* Signaling-related elements, sip-config, sip-interface, session-agent,
and so on.
Security:
* Security-related elements: certificates, IP-Sec, and so on.
NTP-SYNC:
* NTP servers configuration

Configuration Element:
Is a logical grouping of parameters with values assigned to them.
Can be multi-or-single-instance, parent element or subelement (nested) o
r both
General
At any given time there are two configuration loaded in the SBCs RAM: The
"Running" configuration that determines how the SBC provides its services and t
he "Editing" configuration which is initially identical to the running configura
tion an can be changed at any time without affecting the service.
If changes where made in the editing config an have been saved in the da
taDoc.gz file (Last Saved Configuration). Now the two configs in the RAM are dif
ferent, but kept in non-volatile files. When the SBC is rebooted the editing con
figuration RAM area will be loaded from the dataDoc.gz and the running config RA
M area will be loaded from the dataDoc_nn.gz (Last Running Configuration) file.
Lets assume that the last save config is now made to be the runn-config.
The runn-config RAM area will now be overwritten with data from dataDoc-gz file.
Upon the next reboot both editing and running configuration RAM areas will be l
oaded from the dataDoc.gz file.
When an element is created (or modified) and the key you specified is alredy in
use, "error 409" is displayed when done is issued.
Flash File System
display-current-cfg-version - to see configVer.dat
display-running-cfg-version - to see runVer.dat
Backup operations on the SBC save backup copies of configurations, which are rel
atively xmall XML files.
backup-config
backup-config
backup-config
backup-config

<filename>
<filename>
<filename>
<filename>

! when all configuratiosn are sync

running
editing
saved

Restoring backup file is as if you manually created a new configuration in the E

diting Configuration RAM area.
restore-backup-config <filename>
restore-backup-config save (dataDoc.gz)
restore-backup-config running (dataDoc_nn.gz)
display-backups
delete-backup-config <filename>
Clearing the Configuration
delete-config ! Configuration files in /code/gzConfig/ will be deleted,
configuration version will reset to 1. The following will not change:
Boot parameters
Licenses
Passwords
System data and time
++++++++++++++++++++++++++++++++++++++++++++
Create a Phy-interface for every physical interface to be used.

Use the M<slot><port> naming convention

Remember to change operational-type to "media" for the media interfaces.
A network-interface created on top of a media interface will only support VoIP p
rotocols (SIP, H.323, RTP, MGCP/NCS).
Network interfaces define the IP subnet, default gateway, VLAN, and other operat
ional parameters.
Network interfaces thar are bound to media phy-interfaces will only respond to V
oIP protocols.
Management protocol can be remporarily enabled.
Media phy-interface Redundancy
Physical port redundancy is available when only two out the four ports a
re actively used.
configure terminal
system system-config
link-redundancy-state enabled
done
exit
exit
exit
switch-redundancy-link 0 1 ! Switchover can be done manually
Links are sensed every 1 second.
Configuration:
phy-interface
name
operation-type
port
slot
virtual-mac
admin-state
auto-negotiation
duplex-mode
speed
wancom-health-score
overload-protection
last-modified-by
last-modified-date
network-interface
name
sub-port-id
description
hostname
ip-address
pri-utility-addr
sec-utility-addr
netmask
gateway
sec-gateway
gw-heartbeat
state
heartbeat

M00
Media
0
0
enabled
enabled
FULL
100
50
disabled
admin@127.0.0.1
2015-10-08 15:50:27
M00
0
Conexion to SoftPhone
192.168.10.1
255.255.255.0
192.168.10.254
disabled
0

retry-count
retry-timeout
health-score
dns-ip-primary
dns-ip-backup1
dns-ip-backup2
dns-domain
dns-timeout
signaling-mtu
hip-ip-list
ftp-address
icmp-address
snmp-address
telnet-address
ssh-address
last-modified-by
last-modified-date

0
1
0

11
0
192.168.10.1
192.168.10.1

admin@127.0.0.1
2015-10-08 15:57:26

Realms and Realm Bridging

A realm:
Is a collection of VoIP entities residing in one or more networks.
Typically maps to a SP, enterprise, or end-user population environment.
It is defined by a configuration element that contains many parameters that appl
y to the enviorenment.
Is considered as a "Layer 5" definition and a "container" of resources.
Realm Bridging:
Is the routing of a signaling messages coming from a given ingress realm
to a "next hop" in an egress realm
The routing rules (routes, relative cost, and so on) are provided by eit
her "Local-Policy" or "SIP-NAT" configuration elements.
Static bridging: Ingress and egress realms are unconditionally "
paired". Example: A->C; C->A
Dynamic bridging: Egress realm can be any, depending on time-ofday, called number, and so on.
The object of the Oracle Communications SBC is to bridge realms either staticall
y or dinamically.
-----------------------------------------------------------------------------------------------------------------------------------------------------It is very important to remember that the SBC bridging decisions are based solel
y on information found in the signaling messages--never L3 information.
-----------------------------------------------------------------------------------------------------------------------------------------------------Peering Model
The peering model is generally characterized (and there are some excepti
ons) by the fact that no REGISTER requests traverse the SBC.
This model is commonly configured in an SBC that resides between realms:
SP - SP
SP - its point-of-presence
SP - Served enterprise
Access-Backbone Model
The Access model generally characterized by the fact that endpoints send

REGISTER request to a registrar that resides in a different realm.

This model is normally configured in an SBC that resides between realms:
SP - Served end-user population
Enterprise - Remote worker population
End users are registered at the service providers registrar.
Realm Bridging Models for SIP
|---------------------- SIP ----------------------|
|
|
Peering/Trunking --------------------------------- Acces
s/Remote Worker
|
|
Header Manipulation
|
Rules Realm bridging
Homed in Access
(HMRRB)
|
|
--------|

|
|
|
|

|
|
|
|
|

Policy-Based

Single SIP-NAT
|

Realm bridging

|
Network (SSNHAN)
|
|
|
|

(PBRB)
|
|---------------

Open-Access
Single SIP-NAT
Internet (OAI)
Homed in Trusted

|
|
SIP-NA

T Bridge

Network (SSNHTN)
(

SNB)
PBRB: Simplest, most versatile, but not always capable of addressing all issues
HMRRB: Most cmmonly used in peering deployments
SSNHTN: Used in many access deployments if HMRs do not work optimally
SSNHAN and SNB: Archaic, no longer in common use
Realm Bridging Models for H.323
Peering/Trunking - B2BGK - B2BGW
Access/Remote Worker - Registration-Caching - Registration-Proxy
Creating a Realm Configuration Element
realm-config
identifier
description
addr-prefix
network-interfaces
mm-in-realm
mm-in-network
mm-same-ip
mm-in-system
bw-cac-non-mm

core
0.0.0.0
M10:0
disabled
enabled
enabled
enabled
disabled

msm-release
max-bandwidth
fallback-bandwidth
max-priority-bandwidth
max-latency
max-jitter
max-packet-loss
observ-window-size

disabled
0
0
0
0
0
0
0

The SBC configuration is very flexible: A realm can use a dedicated netw
ork-interface or share a network interface with other realms.
SIP Interfaces
The sip-config element:
Must be created in order for the SBC to handle SIP, is a global,
single instance.
The SIPD is the B2BUA application responsable for most of the SBCs signaling beha
vioral features.
The SIP-Interface (The EDGE proxy function) is the SIP protocol stack and makes
the SBC look like a SIP proxy.
Receives and transmits SIP signaling messages, provides a service pipe to the SI
P daemon (sipd).
Define SIP signaling IP addresses, ports, transport protocols, and various SIP p
rocessing policies.
sip-interface
state
realm-id
description
sip-port
address
port
transport-protocol
tls-profile
allow-anonymous
multi-home-addrs
ims-aka-profile

enabled
peer1
192.168.10.1
5060
UDP
all

----------------------------------------A realm can only have one sip-interface.

----------------------------------------show virtual-interfaces
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SBC Media Services
The SBC media proxy, provides network address and port translation (NAPT
) of media (RTP) packets coming from the ingress realm and going out to the egre
ss realm
The media-manager-config Element
Must be created in order for the SBC to handle media, is a global, singl
e-instance.
Defines media handling state, latching, HNT, timers, traffic shapping, a
nd so on.
Latching: RTP source IP address will be taken from the first RTP packet

rather from SDP body. When enabled, the SBC will "lock down" a flow upon receipt
the first RTP packet at an allocated media port.
The steering-pool:
Is the SBCs media interface (for a given realm)
Receives and transmits RTP packets
Defines a media IP address and pool (range) of ports from which port(s)
are dynamically allocated for every established session.
Provides call admission control (CAC) by setting a limit of session goin
g into and out of a realm
Steering pools define sets of ports that are used for steering media flows from
one realm to another through the SBC, through the SDP body, will indicate to the
device to send media there.
In the rewritten SDP body, the SBC replace:
The original IP address with the steering pools IP address.
The original port with a port allocated from the pool.
Steering Pool Configuration
A steering-pool must be assigned to every realm in which media is handle
d by the SBC.
--------------------------------------------------------------------------------------------------A steering pool can only be assigned to ONE realm. But a realm can have more tha
n one steering pool.
--------------------------------------------------------------------------------------------------Steering Pool-Based Call Admission Control
The steering pool size limits the maximum number of current calls (incom
ing+outgoing) in a realm.
A call can "consume" two or four UDP ports.
steering-pool
ip-address
start-port
end-port
realm-id
network-interface
last-modified-by
last-modified-date

192.168.10.1
20000
29999
peer1
admin@127.0.0.1
2015-10-11 00:25:08

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Routing consists of:
Identifying a SIP requests ingress realm,
Applying relevant rules, and
Determining the egress realm and the destination in it where the re-orig
inated SIP request will be sent
It is based on information in the SIP message, NOT on L3 information.
SIPD
Local-Policy

SIP-NAT
Routing
YES

NO

YES

Stati
c and limited
Translation
NO

Very Flexible
YES
For request-URI

YES
For any Header

Via, call-ID, Contact

Route, and record-route
only
Local Policy
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)
Multiple local policies can be (and typically are) created
The Local Policy configuration element contains:
Matching criteria
Zero or more "policy-attributes" subelements, each of which defi
nes a "route"
The SBC is ALWAYS able to determine the ingress realm by:
* Looking through which network-interface then request arrived. If there
is only one realm using that network-interface, then this is the ingress realm.
Or...
* Looking at the requests source IP address. If that IP is known as a ses
sion-agent, that session-agent belongs to the ingress realm looked for. If that
doesnt work then...
* Looking at the requests destination IP address. This IP address is the
sip-interface that serves in ingress realm.
Routing Decision
a.
b.
c.
d.
e.

Determines the ingress realm (always possible)

Look at all LPs configured for the ingress realm
Ignores LPs that have no match to "From" and "To"
Looks at all routes available at this time, in all remaining LPs
Then selects the route (using this procedence):
1. With the lowest COST
2. Matching MEDIA CODEC
3. In the LP with the most specific TO ADDRESS match
4. In the LP with the most specific FROM ADDRESS match
5. With the narrowest DAY IN THE WEEK range
6. With the narrowest TIME OF THE DAY range
7. First configured in the LP that has FROM/TO set to *

Session Agent
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 as more "privileged" device
Benefits of a SA:
The SBC can apply constraints on signaling traffic to/from that device.
The SBC can apply various translations and header manipulations to signa
ling messages to/from that device

The SBC can reject incoming signaling messages from other (non-SA) devic
es
Its name can be user as a next-hop in LP
It can be agruped with other SA in order to form a single logical entity
(Think about redundancy and load-balancing)
Session Agent Groups (SAG)
is a single local element that refers to a group of functionally equival
ent session agents.
Individual constraints might differ for session agents in the gr
oup.
Commonly used for load balancing, a session agent group can functions as
a (single logical) next-hop
That way, traffic sent to this next hop can be load-balanced and
never sent to a group member that is down
The load-balancing scheme can be set to:
Hunt (First SA listed in the group that is responsive)
Round-robin
Least-loaded
Propdist
Lowsusrate
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Header Manipulation Rules (HMRs)
Is an extremely powerful tool by which ANYTHING, in ANY header, can be m
anipulated.
HMRs are based on the "sip-manipulation" configuration element, also ref
erred to as a "rule set"
A rule set contains "header rules"; a header rule may contain "elements
rules"
- A header rule "works" on an entire header
- An element rule "works" on items within a specific header.
When properly applied, a rule-set acts on SIP messages that go through:
A session agent, or
A realm, or
A sip-interface
A rule-set can be applied so it affects either inbound or outbound traffic, oir
both.
An element rule functions on a specific item that can be:
A parameter - Example: ;tag=b5hsskk
A non-parameter Example: +6182928
------------------------------------------------------Parameters in a header have the form ;<name>=<value>:
Referenced by "name"
Other items have various forms
Easily referenced by predefined "types"
--------------------------------------------------------"
Applying Rule Sets
For an existing rule-set to function, it must be "applied" to:
- A session-agent and/or
- A realm and/or
- A sip-interface

Doing so also determines whether the rule-set will act upon incoming or outgoing
SIP traffic
----------------------------------------------------------------SIP manipulations may be applied incoming (BEFORE REALM BRIDGING HAS OCURRED) or
outgoing (AFTER REALM BRIDGING HAS OCCURRED)
----------------------------------------------------------------The header manipulation rules (HMR) mechanism is a key feature for interopeabili
ty.
With HMR, any header and any element in a header can be added, replaced, or remo
ved.
Actions can be unconditional or taken on conditions that can be very simple to v
ery complex.
Rule sets can be tested by SBC commands before being applied.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Peering PBRB Model
Is preerred because it:
Provides the best performance
Is the simplest to configure
Possible issues:
Topology hinding is not guaranteed for all headers fields
The limitation of this model is that the topology is not completely hidden, simp
ly because LP is a routing element and does not affect the SIP message "From:" a
nd "To:" header fields. Those fields and more non-routing header-fields will go
througth the SBC unchanged.
steering pools -- realm-id, address, ports
sip-interfaces -- realm-id, address:port, transport protocol
realms
-- id, net-int
networl-interfaces -- MXX:Y, address
physical-interfaces -- MXX
system-config, sip-config, media-manager
Peering HMRRB Model
The Header Manipulation Rules Realm Bridging (HMRRB) model is the best i
n most deployments because it:
Provides the best topology hidding
Allows any additional header manipulation
Possible issues:
The need to configure and test HMRs.
SIP Peering Access Control
SIP peering access control is archived by configuring the combination odf addres
s-prefix and allow-anonymous
realm-config
identifier
description
addr-prefix
network-interfaces

peer1
192.168.10.0/24
M00:0

mm-in-realm
mm-in-network
mm-same-ip
mm-in-system
bw-cac-non-mm
msm-release

disabled
enabled
enabled
enabled
disabled
disabled

sip-interface
state
realm-id
description
sip-port
address
port
transport-protocol
tls-profile
allow-anonymous

enabled
peer1
192.168.10.1
5060
UDP
realm-prefix

The SBC looks at the IP address in the "Via:" header field and checks wheter it
matches the add-prefix pattern, The allow anonymous parameter, which can be set
differently in each SIP port of a given SIP interface, acts like an "access mode
" control.
For more flexibility, more than one prefix can be set in a realm. This is done u
sing the add-additional-prefix and remove-additional-prefix ACLI commands.
Allow-anonymous
all
agents-only
Realm-prefix

Signaling Traffic allowed

add-prefix

From any source

Ignored

From session-agents only

Ignored
(all other traffic is rejected)
From session-agents AND from
Applied (should
any source whose IP address

non-zero)
matches the add-prefix in the
realm-config
Configuration
local-policy
from-address
to-address
source-realm
description
activate-time
deactivate-time
state
policy-priority
next-hop
realm
action
terminate-recursion
app-protocol
methods
lookup
next-key
last-modified-by

*
*
core

enabled
none
192.168.10.254
peer1
none
disabled
single
admin@127.0.0.1

be

last-modified-date
local-policy
from-address
to-address
source-realm
description
activate-time
deactivate-time
state
policy-priority
next-hop
realm
action
terminate-recursion
app-protocol
methods
lookup
next-key
last-modified-by
last-modified-date
sip-manipulation
name
description
split-headers
join-headers
header-rule
name
header-name
action
comparison-type
msg-type
methods
match-value
new-value
element-rule
name
parameter-name
type
action
match-val-type
comparison-type
match-value
new-value
header-rule
name
header-name
action
comparison-type
msg-type
methods
match-value
new-value
element-rule
name
parameter-name
type
action
match-val-type

2015-10-11 14:30:18
*
*
peer1

enabled
none
172.16.0.100
core
none
disabled
single
admin@127.0.0.1
2015-10-11 14:29:39

NAT_IP

To_hr
To
manipulate
case-sensitive
request
INVITE

To_er
uri-host
replace
ip
case-sensitive
$REMOTE_IP
From_hr
From
manipulate
case-sensitive
request
INVITE

From_er
uri-host
replace
ip

comparison-type
match-value
new-value
last-modified-by
last-modified-date
session-agent
hostname
ip-address
port
state
app-protocol
app-type
transport-method
realm-id
sip-interface
state
realm-id
description
sip-port
address
port
transport-protocol
tls-profile
allow-anonymous
multi-home-addrs
ims-aka-profile

case-sensitive
$LOCAL_IP
admin@127.0.0.1
2015-10-11 15:16:09
phone-ivan
192.168.10.254
5060
enabled
SIP
UDP
peer1
enabled
peer1
192.168.10.1
5060
UDP
agents-only

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Access-Backbone Configuration Models
Policy-Based Realm Bridging (PBRB) - preferred
Single SIP-NAT Homed in Trusted Network (SSNHTN) - provides additional topology
hiding
Single SIP-NAT Homed in Access Network (SSNHAN) - very rarely used
SIP-NAT Bridge (SNB) - no longer being deployed
Access realm: A population of endpoints and proxies; some endpoints or proxies a
re behind a NAT device (for example, a firewall)
Backbone realm: Proxies, registrars, SIP application servers, and gateways.
The Access-backbone model is asymmetrical, in cntrast to the Peering model, whic
h is symmetrical. A key differentiator of an Access-Backbone model is that REGIS
TER messages do cross the SBC.
Access to Backbone - Local Policy or SIP-NAT
Backbone to Access - Registration Caching
Registration Caching: Purpose
The SBC maintains a cache with an entry for each endpoints so that it ca
n:
a. keep endpoint information
Phone number
IP address and port within the access realm
Whether or not it is behind a NAT device
If yes, the NATed IP address and port
b. Route requests from backbone realm to access realm

Cannot use local policies--too many next-hops

c. Efficiently handle endpoints and registrars
When the SBC receives a REGISTER request from an endpoint, it:
a. Finds out whether the endpoints is behind a NAT device
b. Re-originates a REGISTER request and sends it to the registra
r in the backbone realm
c. Receives from the registrar a 200 OK response with expires=x
seconds
d. Creates a registration cachinf entry for this endpoint
e. Re-originates the 200 OK response with expires=y seconds and
sends it to the endpoint
show sipd endoint-ip
Enabling Registration Caching
Registration-caching is set per sip-interface (= per realm)
If set to enabled:
All endpoints will be cached when registered
If set to disabled:
Only endpoints behand NAT will be cached ! only if the nat-tranv
ersal parameters ( is set to "always")
session-router -> sip-interface

Routing by registration caching

Whean A calls B:
The SIP device puts Bs contact URI (from the local database) into the INV
ITEs start-line
The SBC looks up the registration cache for this URIs user-pasrt and find
s out the endpoints IP address
When A calls B:
The SBC, by the default, will use the registration cache entry
on and route the call through itself only.
This is not always desirable.
In order to have the SBC route the call to the SIP device, set
e-to-registrar" parameter enabled, will not use the registration cache
ng, so any message will be routed to the SI device (normally using the
ism).

informati
the "rout
for routi
LP mechan

SIP Hosted NAT Traversal

HNT is a technique that a carrier-hosted border device uses in order to
provide persistent reachability for SIP endpoints located in private LANs behind
NAT devices.
Address issues of:
Ip address and port inconsistencies between L3 and L4 and applic
ation Layer (SIP). This issue also applies to media IP addresses in the SDP body
.
Blocking IP packets considered by the NAT device as "unsolicited
". This applies to signaling as well as to media.
The SBC compares IP addresses in the IP packet and in the SIP message to
find out whether the endpoints IP addresses has been NATed.

Keeps all endpoints related IPa addresses and ports in the registration c
ache, including a flag indicating "behind NAT"
Manipulates registration expiration time in order to make an endpoint re
-register freuently, thus keeping the NAT device open for incoming calls.
The SBC may uses "Adaptative HNT" to optimize for that.
Media Laching (Media Addresses and ports issues)
Two big issues:
1. The initiators SDP body indicates to the other device to send
its media to a destination that is unreachble
2. Any media packet sent to the initiator will be rejected as un
solicited packet (no media port is open in the firewall)
The SBC must wait until the first RTP packet is sent
Only then will the IP:port the media comes from be known and lat
ched by the SBC.
Is a mechanism by which the SBC will "lock down" a flow upon receipt of
the first RTP pacjet at an allocated media port.
Is always enabled when an endpoint is determined to be behind a NAT devi
ce.
Symmetric Latching
Is defined as "symmetric" when:
The endpoint is determined to be behind a NAT device
Media to the endpoint is sent by the SBC to the same IP:Port whe
re it comes from (regardless of the IP:Port in the SDP body)
Access PBRB Model
The policy-based realm bridging (PBRB) model is preferred because it:
Provides the best performance
It the simplest to configure
Possible issues:
Topology hiding is not always guaranted
endpoints should use domain-name-based AORs.
It is common for the devices in the backbone to be configured as session agents.
These devices are typically services providers registrars, proxies, switches, g
ateways, messaging systems, and son on.
Some registrars will reject registration requests if the "To:" field does not in
clude the backbone domain.
Access SSNHTN Model
It uses:
PBRB:
LP for access to backbone routing
Registration-caching backbone to access routing
And in addition:
SIP-NAT mechanismo for good topology hinding
The SIP-NAT environment involves:
One home realm
The SBC is said to reside in this realm
Any number of external realms thah can be
Pairs of peering realms
Access realms

Backbone realms
A SIP-NAT configuration element per each external realm that provides static rou
ting and topology hiding.
In Access-backbone, the backbone realm is normally considered to be a "trusted n
etwork" (SP Network). Id the backbone realm in an Access-Backbone deployment is
assigned as a home realm, then we have an HTN (Homed in Trusted Network) model.
We can have several access realms (all externals)
If the home realm is an access realm, , then we have an HAN (Home in access netw
ork). Here we are limited to one access realm, but we can have more than one bac
kbone realm.
If traffic is exchanged between peering external realms, it must cross the home
realm. This path will be subject to two sip-nat translations (one for each exter
nal realm) and is called SNB (SIP NAT Bridging)
If traffic is exchanged only between an external realm and the home realm, the p
ath is only subject to one sip-translation ans is called SSN (Single SIP-NAT)
SIP-NAT logical model
The SIP-NAT element contains the IP addresses translations and the list of heade
r subject to them
External-proxy-address (EPA)
External-address (EA)
Home-address (HA)
Home-proxy-address (HPA)
session-router -> sip-nat
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Border Element Redundancy Protocol (BERP), interfaces wancom1 and wancom2 to che
ckpoint health, state, media flow, and signaling information.
The HA cluster functioning is closely related to the alarm subsystem.