ACME Net-Net: Step By Step Configuration

Notes
General Description of an SBC (Session Border
Controller)
The usage of an SBC (Session Border Controller) enables enterprises to extend SIP-based
applications beyond the Enterprise network boundaries, e.g., when users of Lotus Sametime
Unified Telephony are not all within the same IP network.
Users within each network may not have public IP addresses and/or NAT (Network Address
Translation) devices may be deployed within the networks. In these cases, SBCs are used to
allow SIP signaling to pass between the user devices and Lotus Sametime Unified Telephony.
The SBC also provides network topology hiding.
An SBC is basically a SIP-aware firewall that also serves as a SIP proxy or B2BUA (Back-toBack User Agent). The Acme Packet Net-Net 2600 and Net-Net 3800 SBCs behaves as a
B2BUA while the Branch and Com dasys SBC behaves as a proxy. The SBC is given a
publicly accessible URL and IP address, and SIP phones in the internet use this as the address
of their SIP registrar and proxy. The SBC also has a second IP address, and a separate LAN
connection, in the corporate LAN. Its function is to analyze, modify, and relay messaging
between the phone and the Lotus Sametime Unified Telephony system. Only proper SIP and
media (RTP, Real-Time Transport Protocol) packets are permitted through the firewall
function.

Basic Functionality of SBC (Session Border

Controller)
An SBC (Session Border Controller), also known as Session Manager or Session Director
enables secure reliable voice, video, and multimedia connections across IP networks.
An SBC provides the following functionalities within Lotus Sametime Unified Telephony:

Remote Access
Subscribers want to use their phones regardless of location. The Acme Packet SBC
enables secure access to the Lotus Sametime Unified Telephony regardless of
public/private network or endpoint type.

SIP Trunking
Enterprise network operators realize the significant operational cost savings by
transitioning from TDM to IP (SIP) trunking. The Acme Packet SBC enables
enterprises to securely connect their IP Telephony solutions to carrier SIP trunking
services or between enterprise branch offices.

Security
Enterprises want their IP telephony network protected against attacks and
compromises. The Acme Packet SBC can be deployed to provide a secure access at all
points of interconnect.

Policy Enforcement
Allows Enterprises to define, enforce, and audit fine-grained policies on real-time
services such as VoIP, video, IM, presence, communications-enable applications and
other real-time services.

Basic Functionality of SBC (Session Border Controller)

An SBC (Session Border Controller), also known as Session Manager or Session Director
enables secure reliable voice, video, and multimedia connections across IP networks.
An SBC provides the following functionalities within Lotus Sametime Unified Telephony:

Remote Access
Subscribers want to use their phones regardless of location. The Acme Packet SBC
enables secure access to the Lotus Sametime Unified Telephony regardless of
public/private network or endpoint type.

SIP Trunking
Enterprise network operators realize the significant operational cost savings by
transitioning from TDM to IP (SIP) trunking. The Acme Packet SBC enables
enterprises to securely connect their IP Telephony solutions to carrier SIP trunking
services or between enterprise branch offices.

Security
Enterprises want their IP telephony network protected against attacks and
compromises. The Acme Packet SBC can be deployed to provide a secure access at all
points of interconnect.

Policy Enforcement
Allows Enterprises to define, enforce, and audit fine-grained policies on real-time
services such as VoIP, video, IM, presence, communications-enable applications and
other real-time services.

Additional SBC (Session Border Controller) Capabilities

Apart from the basic NAT (Network Address Translation), ALG (Application Level Gateway
and Media Relay functions, SBCs (Session Border Controllers) provide many other features
and capabilities that Lotus Sametime Unified Telephony customers may wish to use.
In the following overview, the capabilities of the Acme SBC are listed as an example.

Security
o

Cryptographic authentication

Signaling and media encryption

Stateful signaling and media validation

Denial of service attack mitigation

Intrusion prevention

Routing
o

Least cost routing

MoS-based routing

CAC (Call Admission Control)

Presence-based routing

Business rule determination

Monitoring
o

Session detail recording

QoS (Quality of Service) detail recording

Instant message recording

Voice and video recording

File transfer recording

System and admin event logging

Control

Signaling and media control

QoS control

Identity-based access control

File transfer control

Instant message content control

URL access control

Interoperability
o

Multi-vendor protocol normalization

SIP-aware NAT traversal

Application-aware session routing

H.323 interworking with SIP

IPv4 / IPv6 interworking

Corporate directory integration

SBC (Session Border Controller) Functionality Dynamic Port Mapping

The Dynamic Port Mapping allows the usage of a single IP address, where the different users
are separated via unique ports.
There are different scenarios for Remote Users and Branch Offices.

Remote Users

UDP connections on the core side between the SBC (Session Border Controller) and
Lotus Sametime Unified Telephony
On the core side of the SBC a single IP address is used, but unique ports are assigned
for each user.

TCP/TLS connection on the core side between the SBC and Lotus Sametime Unified
Telephony
On the core side of the SBC a single IP address is used but unique ports are assigned
for each user. Only a single layer 3 connection is used but unique port numbers are

sent in the 2nd Via header field and in the Contact header field to Lotus Sametime
Unified Telephony.

Branch Office

UDP/TCP/TLS connections on the core side between the SBC and Lotus Sametime
Unified Telephony.
On the core side of the SBC a single IP address is used per Branch, but unique ports
are assigned for each user. Only a single layer 3 connection is used but the unique port
numbers are sent in the 2nd Via header field and in the Contact header field to Lotus
Sametime Unified Telephony.

SBC (Session Border Controller) Functionality Support for Branch Survivability

In order to allow fast detection of connectivity loss, particularly in low traffic periods, the
SBC (Session Border Controller) must support receiving and sending SIP OPTIONS requests
between survivable branch proxies and the Telephony Control Server. This allows the branch
to switch to survivable mode and the Lotus Sametime Unified Telephony server to invoke
automatic rerouting to the branch via the PSTN (Public Switched Telephone Network).
In order to allow the Telephony Control Server to differentiate between a branch users UA
(User Agent) not responding and a WAN outage the SBC must send a SIP 504 response for
SIP request timeouts occurring for requests sent to a branch proxy. At normal traffic levels
connectivity failures are likely to be detected by SIP requests timeouts before they are
detected by the SIP OPTIONS audit mechanism.

SBC (Session Border Controller) Functionality Registration Caching and Unregistering

Functional Sequence
1. The remote user sends a SIP REGISTER request to the public IP address of the SBC.
2. The SBC assigns a private IP address and port on the core side.
3. The SBC establishes a binding between the remote users IP address and the associated
IP address and port on the core side.
4. The SBC replaces the contact address with the private IP address and port that it has
assigned for the remote user.
5. The SBC then delegates (i.e. passes on) the SIP REGISTER request to the Telephony
Control Server.
The SBC uses a port mapping technique so that only one contact IP address is used for all the
remote users but each user is assigned a unique port number at the single IP address.

When Lotus Sametime Unified Telephony wishes to route a call to a remote user, ...
1. it sends a SIP INVITE to the topmost Via header address previously received in the
SIP REGISTER request from the SBC, i.e. the SBC core-side interface
2. it associates the Contact address in the SIP INVITE received at an IP address/port on
the core-side with a specific remote users public IP address/port. For this step the SBC
uses the registration binding information.
3. it forwards the SIP INVITE from the access-side of the SBC to the remote user's
device.

System Specific Information

When a phone is reset, a SIP REGISTER with expiration time = 0 should be sent from the
phone to remove the registration contact binding in the SBC and the Telephony Control
Server. If the SBC detects a registration timer expiration for a user it must remove its
registration contact binding and send a REGISTER with expiration time = 0 to the Telephony
Control Server.

SBC (Session Border Controller) Functionality SBCs and Data Firewalls

SBCs (Session Border Controller) and data firewalls are complementary. The SBC has
integrated firewall capabilities on both access and core side and therefore exists in its own
DMZ (Demilitarized Zone) for SIP signaling and RTP (Real-time Transport Protocol)/SRTP
(Secure Real-time Transport Protocol) media, while the data firewall handles data protocols.
Voice and data traffic should be separated by edge routers into different Virtual LANs
(VLANs). The voice VLAN is routed to the SBC and the data VLAN is routed to the data
firewall.
If the Enterprise security policies mandate firewalls in front of the SBC then the SBC can use
procedures to keep the necessary VoIP ports open through the firewall, e.g., short registration
refresh intervals on the access side of the SBC, or TLS (Transport Layer Security)/TCP keep
alive procedures. Alternatively the necessary VoIP ports may be opened statically at the
firewall.

SBC (Session Border Controller) Configuration Connection of Remote Users

When the remote user is a hard phone there is generally no support for a VPN connection at
the phone and use of an SBC (Session Border Controller) to allow connection to the
Telephony Control Server is necessary.
Even when use of VPNs is possible it is advantageous to use the SBC solution for remote
users so that the difficulties of supporting and managing large numbers of VPNs are avoided.
The SBC in the main office data center is given a publicly accessible URL and IP address,
and the home workers use this as the address of their SIP Registrar and SIP Server for their
SIP phones or SIP soft clients. The SBC also has a second IP address, and a separate LAN
connection, in the corporate LAN, to communicate with the server.

The following redundancy considerations apply for remote users:

Lotus Sametime Unified Telephony cluster nodes are co-located in one data center (or
geo-separated but in the same sub-net).
If a High Availability SBC cluster is deployed, then failure of one SBC is transparent
to the branch users.
If a non-redundant SBC is used then failure of the SBC results in loss of service until
the SBC is repaired.

Lotus Sametime Unified Telephony cluster nodes are geo-separated in different data
centers with different sub-nets.
A data center outage requires the users to register with the SBC in the other data
center before they can originate or receive new calls. In this scenario the phones must
be configured with the IP addresses of the SBC's in both data centers and must
register with the secondary SBC when connectivity to the primary SBC is lost.

Parent topic: SBC (Session Border Controller)

ACME setup steps:

1. configure system elements
2. configure physical interfaces
3. configure network interfaces
4. configure sip-config
5. configure media-manager
6. configure realm-config
7. configure sip-interfaces (and sip-ports)
8. configure session-agents
9. configure local-policy
10. configure steering-pools
11. verify-config
12. save-config
13. activate-config

I put what I though the relationships are on the ACME. This is what I think it is.

I had a lab ACME that I was working on that I already had some configuration on it. Its a
working config, and I wanted to practice adding some config into it. I added two realmconfigs, two steering-pools, two sip-interfaces and a local-policy.
TestACME# config t
TestACME(configure)# media-manager
TestACME(media-manager)# realm-config
TestACME(configure)# media-manager
TestACME(media-manager)# realm-config
TestACME(realm-config)# identifier Outside
TestACME(realm-config)# network-inter m10:0
TestACME(realm-config)# out-man NAT_IP
TestACME(realm-config)# account disabled
TestACME(realm-config)# exit
Save Changes [y/n]?: y
**TestACME(media-manager)# realm-config
**TestACME(realm-config)# identifier Inside
**TestACME(realm-config)# network-interfaces m00:0
**TestACME(realm-config)# out-man NAT_IP
**TestACME(realm-config)# exit
Save Changes [y/n]?: y
**TestACME(media-manager)# steering-pool
**TestACME(steering-pool)# ip-add 192.168.9.91
**TestACME(steering-pool)# start-port 7000
**TestACME(steering-pool)# end-port 7999
**TestACME(steering-pool)# realm-id Outside
**TestACME(steering-pool)# exit
Save Changes [y/n]?: y
steering-pool
ip-address
192.168.9.91
start-port
7000
end-port
7999
realm-id
Outside
network-interface
last-modified-by
admin@10.1.1.1.
last-modified-date
2013-11-18 14:35:22
**TestACME(media-manager)# steering-pool
**TestACME(steering-pool)# ip-add 192.168.90.75
**TestACME(steering-pool)# start-port 7000
**TestACME(steering-pool)# end-port 7999
**TestACME(steering-pool)# realm-id Inside
**TestACME(steering-pool)# exit
Save Changes [y/n]?: y
steering-pool
ip-address
192.168.90.75
start-port
7000
end-port
7999
realm-id
Inside

network-interface
last-modified-by
last-modified-date

admin@10.1.1.1.
2013-11-18 14:36:37

**TestACME(media-manager)# exit
**TestACME(configure)# session-router
**TestACME(session-router)# sip-interface
**TestACME(sip-interface)# realm-id Outside
**TestACME(sip-interface)# sip-port
**TestACME(sip-port)# address 192.168.9.91
**TestACME(sip-port)# port 5060
**TestACME(sip-port)# transport-protocol udp
**TestACME(sip-port)# allow-anonymous all
**TestACME(sip-port)# exit
Save Changes [y/n]?: y
sip-port
address
192.168.9.91
port
5060
transport-protocol
UDP
tls-profile
allow-anonymous
all
ims-aka-profile
**TestACME(sip-interface)# trans-expire 14
**TestACME(sip-interface)# out-manipulationid NAT_IP
**TestACME(sip-interface)# rfc2833-mode preferred
**TestACME(sip-interface)# add-sdp-invite invite
**TestACME(sip-interface)# add-sdp-profiles G729 PCMU telephone-event
**TestACME(sip-interface)# exit
Save Changes [y/n]?: y
**TestACME(session-router)# sip-interface
**TestACME(sip-interface)# realm-id Inside
**TestACME(sip-interface)# sip-port
**TestACME(sip-port)# add 192.168.90.75
**TestACME(sip-port)# port 5060
**TestACME(sip-port)# transport-protocol udp
**TestACME(sip-port)# allow-anonymous all
**TestACME(sip-port)# exit
Save Changes [y/n]?: y
sip-port
address
192.168.90.75
port
5060
transport-protocol
UDP
tls-profile
allow-anonymous
all
ims-aka-profile
**TestACME(sip-interface)# trans-expire 14
**TestACME(sip-interface)# out-manipulationid NAT_IP
**TestACME(sip-interface)# rfc2833-mode preferred
**TestACME(sip-interface)# exit

Save Changes [y/n]?: y

**TestACME(session-router)# local-policy
**TestACME(local-policy)# from-add *
**TestACME(local-policy)# to-add *
**TestACME(local-policy)# source-realm Inside
**TestACME(local-policy)# policy-attributes
**TestACME(local-policy-attributes)#
**TestACME(local-policy-attributes)# next-hop 4.3.4.3
**TestACME(local-policy-attributes)# realm
Outside
**TestACME(local-policy-attributes)# action
replace-uri
**TestACME(local-policy-attributes)# terminate-recursion
disabled
**TestACME(local-policy-attributes)# exit
Save Changes [y/n]?: y
policy-attribute
next-hop
4.3.4.3
realm
Outside
action
replace-uri
terminate-recursion
disabled
carrier
start-time
0000
end-time
2400
days-of-week
U-S
cost
0
app-protocol
state
enabled
methods
media-profiles
lookup
single
next-key
eloc-str-lkup
disabled
eloc-str-match
**TestACME(local-policy)# exit
Save Changes [y/n]?: y
local-policy
from-address
*
to-address
*
source-realm
Inside
description
activate-time
N/A
deactivate-time
N/A
state
enabled
policy-priority
none
last-modified-by
admin@10.1.1.1.
last-modified-date
2013-11-18 14:47:02
policy-attribute
next-hop
4.3.4.3

realm
Outside
action
replace-uri
terminate-recursion
disabled
carrier
start-time
0000
end-time
2400
days-of-week
U-S
cost
0
app-protocol
state
enabled
methods
media-profiles
lookup
single
next-key
eloc-str-lkup
disabled
eloc-str-match
**TestACME(session-router)# exit
**TestACME(configure)# exit
ACME Packet: How To Change The System Clock/Time On A 4250 ACME Packet
Net-Net Device
ACME01# show clock
05:25:13 UTC THU OCT 22 2013
ACME01#
ACME01# systime-set
Date YYYY MM DD: 2013 10 24
Time HH MM: 08 04
WARNING: Changing the time can have an adverse
effect on session processing
Do you want to continue [y/n]?: y
Setting time to: THU OCT 24 08:04:00 2013
ACME01# save-config
ACME Packet 4250 Net-Net: How do you take a capture from an ACME 4250 NetNet device?
To turn logging on, do the following:
ACME4250# notify sipd debug
ACME4250#
enabled SIP Debugging
ACME4250# notify sipd siplog
ACME4250#
To turn logging off, do the following:
ACME4250# notify sipd nodebug

ACME4250#
disabled SIP Debugging
ACME4250# notify sipd nosiplog
ACME4250#
Now you have to get the logs. You will need to FTP into the ACME box and get
the logs, like
this:
C:\Users\shane>ftp 10.1.1.1
Connected to 10.1.1.1.
220 ACME4250 FTP server (VxWorks 6.4) ready.
User (10.1.1.1:(none)): shane
331 Password required for user.
Password: password
230 User user logged in.
ftp> cd /ramdrv/logs
250 CWD command successful.
ftp> asc
200 Type set to A.
ftp> get sipmsg.log
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/sipmsg.log' (131546
bytes).
226 Transfer complete.
ftp: 135087 bytes received in 0.23Seconds 577.29Kbytes/sec.
ftp> get log.sipd
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/log.sipd' (625802
bytes).
226 Transfer complete.
ftp: 634808 bytes received in 0.39Seconds 1627.71Kbytes/sec.
ftp> bye
221 Goodbye.

ACME Net-Net: How To See The License Info

Sometimes I just need to know what licensing is on the ACME Net-Net box. Here is how
you do this:
ACMESYSTEM#
ACMESYSTEM# config t
ACMESYSTEM(configure)# system
ACMESYSTEM(system)# license
ACMESYSTEM(license)# show
License #1: 4000 sessions, SIP, H323, QOS, ACP, Routing, Load Balancing,
Accounting, High Availability, ENUM, DoS, IDS,
IDS Advanced

no expiration
installed at 09:55:30 OCT 29 2013
Total session capacity: 4000
ACMESYSTEM(license)#