Comfort Noise (RFC 3389) is the noise played in an RTP stream to prevent a user form hearing total silence on the connection. Not all telephony systems have the ability to play music while a party is on hold.  Without Comfort Noise (CN) the party on hold may think the connection dropped.

Starting with ECZ740 the Acme Packet SBC has the ability to inject Comfort Noise into an RTP stream by analyzing the SDP Offer and SDP Answer from both SIP endpoints. CN interworking is triggered on a per realm basis.

In the example below the calling party (Skype for Business) SDP Offer contains CN and is traversing a realm called core which has CN interworking enabled. The SBC forwards SDP to the called party. If the called party SDP Answer contains CN the SBC does not do anything because both endpoints support Comfort Noise. If CN is not present in the PSTN’s SDP Answer the SBC adds CN to the egress SDP Answer (towards Skype for Business) and will take responsibility for injecting CN into the RTP stream.

Example SBC configuration

Example call flow where SBC inserts comfort noise when Skype for Business sends CN during an active call

Comfort Noise state is exchanged with Active-Standby units high availability SBC pair. If there is a mid call failover and the standby becomes active, it will honor the CN message exchange between the called and calling party and generate Comfort Noise.

Additional document may be found in the ECZ740 Configuration Guide which is publicly accessible here.

 

Media injection may be configured on the Acme Packet SBC using the Local Media Playback SPL. An SPL is a plug-in on the SBC based on LUA scripting and each SPL on the SBC enhances its features and capabilities.

The Local Media Playback SPL is included in the base code of eCZ730m2 and later releases.

The following are the playback options and determine when it’s triggered:

  • playback-on-183-to-originator
  • playback-on-183-from-terminator
  • playback-on-refer
  • playback-on-header

Media files must be properly encoded in the expected codec then uploaded to the /code/media folder on the SBC.

The following example shows User A calling User B. The called party (B) responds with 183 Session Progress. Let us assume 183 is causing no ringback (common) and we want to use the SBC to insert the ringback tone. The SBC knows to stop playing media once 200 OK is received and it will proxy media from the endpoints.

 

Setting up the Playback Configuration

The next step is to enable the spl-config option in the session-agent configuration. It can be applied to multiple session-agents. Another alternative is set the spl-config on a Realm.

The SBC will send MAJOR alarms if there are issues with playback. The following commands show playback statistics and errors.

 

Acme Packet SBC documentation is publicly available here.

Advanced Logging is a recently added feature of the Oracle Acme Packet SBC. Think of it as a way to log all the SIP dialog (and optionally media stats) for a specific call, or, SIP calls that have an “interesting” set of criteria amongst them.

The following are different ways to perform Advanced Logging:

  • SIP Requests such as INVITE or SUBSCRIBE
  • Specific user or host portion in a TO header
  • Specific user or host portion in a FROM header
  • Specific Session-Agent
  • Specific Realm Name
  • Matching Call-ID
  • Rate Limiting

The scope of the logging determines how much of the call is logged

  • request-only – Logs the matched message
  • transaction – Logs the request and the response
  • session – Logs all messages that are part of the matched session
  • session and media – Same as session plus includes media information

An included SPL is used to enter the logging criteria. The following example matches a specific realm.

# spl set sip advanced-logging in-realm <realm-id>

# config t > sip-advanced-logging

The condition is where the match type and value is defined. Advanced Logging can use AND OR. If there are two conditions AND will require both match for logging to occur. OR will allow a match on one condition.

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. The Whitelist section permits all calls based on the From header matching acmepacket.com 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 show fraud definitions and whether any matches exist. You can also use show-fraud-protection all matches-only and show-fraud-protection blacklist or show-fraud-protection blacklist matches-only

 

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

MOS

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 sip.apkt.com 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 sip.apkt.com 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 [72.12.135.250=16384+Access]
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 [10.12.135.250=16384+Core]
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#

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
completed

14:44.154 On [0:0]72.12.135.250:5060 received from 72.12.135.2:56883
REGISTER sip:acmepacket.local SIP/2.0
Via: SIP/2.0/UDP 172.20.10.4:56883;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@172.20.10.4:56883;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0

—————————————-

14:44.158 On [0:0]72.12.135.250:5060 sent to 72.12.135.2:56883
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 172.20.10.4:56883;received=72.12.135.2;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