Acme Packet SBC Easter Egg – Part 1

Posted: 7th March 2016 by Mark in Cisco

There are two easter eggs in the SBC’s ECZ Web Gui (Basic Mode). If you’re at Enterprise Connect 2016 then come by the Oracle booth and see if you can find the first one.


The release of Acme Packet ECZ730m1 software introduces the ACLI command fraud-protection. This allows the SBC to store multiple black lists, white lists, SIP redirect lists, and rate limit entries for fraud prevention and call control. Multiple lists may exist where entries are stored in separate XML files.

Lists (XML files) may be initially created through the command line (ACLI) or web interface. If the preference is to manage lists manually then once a list is created it will need to be downloaded and the XML file(s) edited with a text editor, similar to managing Local Route Tables (LRT). Otherwise, all entries may be added, modified, or deleted using the web interface.

Below is an example of the GUI configuration elements for managing fraud-protection











Below is an example of creating a new fraud-protection XML file in the ACLI called test.xml

In the example below, the Whitelist section permits all calls based on the From header matching through the realm called peer, as well as calls to based on the To header specific UK phone number on any realm (the * is a wildcard for all realms) . The Blacklist section rejects calls based on a variety of criteria. Note that even though calls are blocked to +44 based on the To header, calls to +441189240000 are permitted since this is a more specific match in the Whitelist.

The command show fraud-protection all will shoe whether fraud definitions and whether any matches exist


The command show fraud-protection stats show a summary version of matches








Often times when deploying network monitoring probes they are passive devices tapped into the network using port spans, also known as port mirroring. Since the Acme Packet SBC is acting as a SIP b2bua and sees all SIP traffic it also has the ability to act as a probe without the need for port spans or mirroring.

Using IPFIX (IP Flow Information Export) the SBC will provide real-time statistics to the Oracle Communications Operations Monitor (formerly Palladion) Mediation Engine. The ME is able to provide real-time SIP ladder diagrams, call correlation, detect one-way RTP audio streams, provide alerting (fraud detection, call failures, emergency 911), display SBC configs, report on degraded MOS and RFactor scores, as well as show devices performing SIP Registration through the SBC and their associated endpoint make, model, and firmware information.

Currently Operations Monitor is the only platform I am aware of that can perform all of this real-time with no delay or lag. SIP ladder diagrams will display and continue to refresh in real-time whether a call is in progress or mid-call with intermediary dialog taking place.

All traffic traversing through the SBC north and southbound is reported using IPFIX 

Screen Shot 2015-06-20 at 8.43.19 AM


The network-interface configuration element on the SBC determines which interface is used to send the IPFIX Export Data to the Mediation Engine. In most cases it will be the Management interface although it could be a slot0 or slot1 interface if desired.
Screen Shot 2015-06-19 at 9.17.21 PM







Oracle Operations Monitor’s Mediation Engine supports an interactive multi-tenant web interface using HTML 5.

Screen Shot 2015-06-19 at 10.32.50 PM


While the SBC is sending IPFIX Export Data the Operations Monitor platform will display SIP ladder diagrams on a per call basis showing a correlated call flow in real-time. 

Screen Shot 2015-06-19 at 9.47.28 PM




Hover the mouse over a SIP message for more detail

Screen Shot 2015-06-19 at 9.47.49 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Left click to lock multiple floating windows in place for additional visibility into multiple messages at the same time

Screen Shot 2015-06-19 at 9.48.43 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Use the View option for more details such as CODEC, IP address, DTMF Events

Screen Shot 2015-06-19 at 9.51.53 PM

Screen Shot 2015-06-19 at 10.11.34 PM

View MOS scores in 10 second intervals for active calls for Called and Calling directions


Screen Shot 2015-06-19 at 10.11.34 PM

Additional voice quality details are provided for each hop where media is anchored
Screen Shot 2015-06-19 at 9.27.24 PM

Screen Shot 2015-06-19 at 10.11.34 PM

SIP segments within a single call are broken down with additional details.

Note the PCAP export button for Wireshark compatibility (and PDF export)

Screen Shot 2015-06-19 at 9.58.56 PM

Screen Shot 2015-06-19 at 10.11.34 PM

See which Remote Workers or Hosted IP PBX endpoints are registering SIP through the SBC

Screen Shot 2015-06-19 at 10.03.42 PM

Screen Shot 2015-06-19 at 10.06.54 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Call correlation with five SIP hops 
Screen Shot 2015-06-19 at 9.36.49 PMScreen Shot 2015-06-19 at 10.11.34 PM

View all calls traversing the network or call through a specific named “device” (SBC, IP PBX, Softswitch, Gateway, SIP Proxy, etc.)

Screen Shot 2015-06-20 at 11.29.13 AM

Screen Shot 2015-06-19 at 10.11.34 PM

Example of creating a new Alert when voice quality degrades

Screen Shot 2015-06-19 at 10.21.24 PM

Screen Shot 2015-06-19 at 10.23.23 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Create custom “apps” 

Screen Shot 2015-06-19 at 10.24.30 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Use 200+ different Key Performance Indicators (KPI) or make custom KPI’s

Screen Shot 2015-06-19 at 10.28.24 PM

Screen Shot 2015-06-19 at 10.28.29 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Track calls by specific user

Screen Shot 2015-06-19 at 10.30.50 PM

Screen Shot 2015-06-19 at 10.11.34 PM

Create unique captures per user or device (SBC, Gateway, Softswitch, PBX)

Screen Shot 2015-06-20 at 11.16.51 AM

Screen Shot 2015-06-19 at 10.11.34 PM

To create a unique capture filter enter a telephone number or IP address. 

Screen Shot 2015-06-20 at 11.17.18 AM

Screen Shot 2015-06-19 at 10.11.34 PM

View trending voice quality metrics for the entire network. Notice there are some problematic RTP streams

Screen Shot 2015-06-20 at 11.22.13 AM

Screen Shot 2015-06-19 at 10.11.34 PM

Click on the red and see what device are in the RTP path effecting the MOS score

Screen Shot 2015-06-20 at 11.21.44 AM

The Acme Packet SBC is now on ACLI 7.3 code. Since the release of 7.x there have been a number of new enhancements. One of the most useful new features is Advanced Logging. This is like getting debug output in a log file without having to enable full debug. By setting a condition (or set of conditions) the SBC will capture the interesting traffic to a log file.

The Advanced Logging feature was created using Session Plugin Language (SPL). For those not familiar with SPL it is a plug-in language for the SBC based on the Lua scripting language. SPL provides an easy way to expand the SBC’s capabilities.

The first step is to enable the SPL and set the condition to match for logging. The below example sets advanced-logging for any call coming from phone number 4045551212.

Screen Shot 2015-03-10 at 11.59.28 AM
By adding the additional line below only calls from 4045551212 to 7815551212 will be logged.

Screen Shot 2015-03-10 at 12.08.55 PM

When finish it is recommended to disable advanced-logging using spl stop sip advanced-logging

It is possible to create different Advanced Logging profiles so they may be easily reused at another time without manually entering complex strings each time logging is enabled.

Screen Shot 2015-03-10 at 12.37.40 PM


The following are the advanced-logging options which may be set.

Screen Shot 2015-03-10 at 12.25.31 PM

Screen Shot 2015-03-10 at 12.25.52 PM

For those interested in the Acme Packet BCP documents, they are steadily reemerging as they are being updated with new content.

Previously they were available to customers who had access to the Acme Packet TAC portal. Fortunately they are now available to anyone who has an account on the Oracle-Acme Packet Community site located here.

Also worth noting is that all Acme Packet product documentation is publicly available here.  Enjoy!

The Acme Packet SBC supports the ability to load balance SIP traffic several difference ways. Simply stated, a SIP invite will ingress to the SBC. The SBC will lookup the destination and if it results in a Session Agent Group (SAG) configuration with 2 or more Session Agents, the SBC will egress the SIP invite using one of the selected load balancing algorithms such as Least Busy.

The SBC also supports DNS SRV records for load balancing. For those not aware of what DNS SRV means, it’s a form of DNS that allows a single domain name (associated with a service and protocol) to resolve to many possible destinations. The destinations may be equal or weighted differently. The following is an example of a DNS SRV record for SIP over UDP looks like. In this case all records have an equal weight of 10.

Screen Shot 2014-10-29 at 8.38.35 PM

The domain name will resolve to 5 different A records. The lookup must be a DNS SRV lookup for this to resolve correctly. In this case we are using SIP over UDP as the service which has been defined in Bind.

Here is how to enable DNS SRV load balancing on the SBC. Note this complies with RFC 3263 “Locating SIP Servers”. Once the config has been saved and actives the SBC will ping the address resolved by to see which IP’s are in service.

Screen Shot 2014-10-29 at 8.57.04 PM

Now when a SIP Invite ingresses the SBC and matches a local-policy where the destination next-hop utilizes DNS SRC load balancing the traffic will be balanced across all nodes.

Screen Shot 2014-10-29 at 9.13.13 PM

The grep tool is a very popular Unix command line utility used to match a regular expression. Although “grep” doesn’t specifically exist on the Acme Packet SBC the find command serves a similar purpose.  This feature was introduced in ACLI release 6.4.

NNOS-SD# find [configuration | running-config | command]  [attribute]

NNOS-SD# find ?

<string>               find the specified string
command              find command within menus
configuration        find in editing configuration
running-config      find in running configuration

** My SBC has a realm called Access and I want to know where Access resides in the configuration **

NNOS-SD# find running-config Access

session-router -> local-policy [Access; *; *]
source-realm Access
description Access to Core

system -> network-interface [s0p0:0]
description Access

media-manager -> realm-config [Access]
identifier Access

session-router -> sip-interface [Access]
realm-id Access

media-manager -> steering-pool []
realm-id Access

Found 6 instances

NNOS-SD# find running-config Core

session-router -> local-policy [Access; *; *]
description Access to Core

session-router -> local-policy [Access; *; *] -> local-policy-attribute [Core; SAG:BW-APP-SERVERS]
realm Core
realm Core

system -> network-interface [s1p0:0]
description Core

media-manager -> realm-config [Core]
identifier Core

session-router -> session-agent [as1]
realm-id Core

session-router -> sip-config
home-realm-id Core

session-router -> sip-interface [Core]
realm-id Core

media-manager -> steering-pool []
realm-id Core

** I want to know what configuration elements support local-policy **

NNOS-SD# find local-policy
Command menu —————————–
(root) show configuration local-policy
(root) show running-config local-policy
(configure) session-router local-policy

Running configuration ——————–

Found 3 instances

NNOS-SD# find force
Command menu —————————–
(root) halt force
(root) reboot force
(root) reboot fast force
(root) show configuration enforcement-profile
(root) show running-config enforcement-profile
(configure) media-manager realm-config enforcement-profile
(configure) session-router enforcement-profile
(configure) session-router session-agent enforcement-profile
(configure) session-router session-router force-report-trunk-info
(configure) session-router sip-config enforcement-profile
(configure) session-router sip-interface enforcement-profile

Running configuration ——————–

The tail program is available on Unix operating systems and is used to view the tail end of  a text file or piped data. Once tail is running for a particular log file, and as the log file get populated with new data, the newly populated content is displayed on the screen real-time. This saves a step from having to use more or cat after the fact where a user would have to scroll all the way through the log file to the end in order to view the newly added data (and more data may continuously be added making it even more inconvenient).

In the case of the Acme Packet SBC, retrieving log files for viewing typically requires downloading them via FTP/SFTP. The Acme Packet SBC now supports tail from ACLI.

In the following example I want to see what dialog is happening when trying to register a SIP phone through the SBC.  It is possible to tail different log files.

NNOS-VM# notify sipd siplog

NNOS-VM# tail-logfile-open sipd sipmsg.log

waiting 1200 for response to request

14:44.154 On [0:0] received from
REGISTER sip:acmepacket.local SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPjjWHgcYsrr-T9bPbaZ1-hzFTE-U70g.F2
Route: <sip:acmepacket.local;lr>
Max-Forwards: 70
From: “Mark Holloway-8001” <sip:7818018001@acmepacket.local>;tag=q.wbz5RZXd30uc7RwV2IP4GmSCGKDTwl
To: “Mark Holloway-8001” <sip:7818018001@acmepacket.local>
Call-ID: VV5Yro3MQmi7fXX1CDeDax79zDnR.5jN
CSeq: 55540 REGISTER
User-Agent: Telephone 1.1.4
Contact: “Mark Holloway-8001” <sip:7818018001@;ob>
Expires: 300
Content-Length: 0


14:44.158 On [0:0] sent to
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP;received=;branch=z9hG4bKPjjWHgcYsrr-T9bPbaZ1-hzFTE-U70g.F2;rport=56883
From: “Mark Holloway-8001” <sip:7818018001@acmepacket.local>;tag=q.wbz5RZXd30uc7RwV2IP4GmSCGKDTwl
To: “Mark Holloway-8001” <sip:7818018001@acmepacket.local>;tag=aprqngfrt-ejkv9p0000m9f
Call-ID: VV5Yro3MQmi7fXX1CDeDax79zDnR.5jN
CSeq: 55540 REGISTER


NNOS-VM# notify sipd nosiplog

NNOS-VM# tail-logfile-close sipd sipmsg.log

With the recent release of the Acme Packet E-CX 6.4m2 software the SBC now supports Remote Survivability. This is applicable in both a Service Provider Hosted IP PBX environment and Enterprises with large remote office using SIP phones that register to an IP PBX in a centralized Data Center model.

In this example I will focus primarily on the Service Provider model, although it’s just as relevant to the Enterprise model mentioned above since we are talking about remote phones registering over the WAN to a Softswitch or IP PBX. In the diagram below the SIP phones register from the Enterprise site over the Internet or MPLS network to the Service Provider core where a Broadsoft BroadWorks Softswitch resides. For those note familiar with BroadWorks, think of it as a very large software platform that has the ability to virtualize what looks like many IP PBX’s, each for dedicated customers. Most notably in large deployments it is common to see some sort of SIP enabled Firewall, ALG, or SBC (preferred) on the Enterprise premise. All SIP communication, including SIP registration and originated SIP calls, will egress the Enterprise phones through the SBC up into the Service Provider’s SBC and to BroadWorks. Even if calls are destined for another phone extension in the same Enterprise premise the call must go through the carrier core where CDR’s will be generated and any other Class 5 features may be provided for the call hair pinning back into the Enterprise to a different extension.

Screen Shot 2013-11-14 at 11.26.09 AM


One of the biggest challenges is what happens if the SP core is unreachable. All registrations and call processing will fail, even for calls destined to another phone extension in the same Enterprise, since the SIP Invite must be able to reach the BroadWorks Softswitch or IP PBX to ring another extension in the same location.

Screen Shot 2013-11-14 at 11.36.53 AM


If the Enterprise is using an Acme Packet SBC on premise the Survivability Mode will use either the P-Asserted Identity from the SIP endpoint or optionally the BroadWorks Survivability method using XML. When the SP Core or Enterprise data center becomes unreachable the Survivability Health Score degrades and the SBC knows to process registration and call traffic locally without sending the traffic to the SP Core.

In Survivability Mode phone A has the ability to call phone C even when the SP Core is unreachable. If the Enterprise normally uses abbreviated dialing such as 4-digit extensions, this will still continue to work, as well as dialing the full phone number.

Screen Shot 2013-11-14 at 11.51.20 AM


Some Enterprises may want to have a local SIP Gateway (such as a Cisco ISR or Adtran Total Access IAD) on premise and utilize one or more PRI’s connected for PSTN access when the SP Core is unreachable. Depending on the Service Provider, the same SP used for SIP Services may also route to the PRI for overflow/outage scenarios so the Enterprise has both inbound and outbound redundancy on premise. The call originated from the SIP network the PSTN where there is no matching Address of Record for SIP phones, the SBC will route the calls to the SIP-PSTN Gateway.

Screen Shot 2013-11-14 at 12.06.10 PM


Below is a basic Remote Survivability configuration.

Screen Shot 2013-11-14 at 12.33.10 PM

Best-practice is to enable SIP Options Ping for each Session Agent. This way the SBC will pro-actively know when a Session Agent is in-service or out of service and degrade the health score appropriately.

The following has been a basic introduction to the Acme Packet Remote Survivability feature. There is more functionality and detail that may be applied and is well documented in the E-CX Maintenance Guide. Although a subset of this functionality has existed on other SIP ALG platforms in the past, Acme Packet has introduced many great new features relevant for Remote Survivability that do not exist elsewhere. All the resiliency and High-Availability that is inherent to the Acme Packet platform remains intact even when Remote Survivability is engaged.


This short tip tends to slip through the cracks sometimes. If you prefer not to have your SBC output display all at once simply enable the more ACLI element.

Screen Shot 2013-10-17 at 3.53.52 PM

Also, you can display just the specific show run element you are looking for. The example below will show whatever local-policy elements are configured on the system.

Screen Shot 2013-10-17 at 3.48.42 PM


There is the ability to filter output based on specific criteria. Options will vary depending on which running-config element entered.

Screen Shot 2013-10-21 at 9.12.07 AM


Either the entire output of the running-config or the sub-elements may be output to a file and retrieved through FTP via the management interface.

Screen Shot 2013-10-21 at 9.16.29 AM