Net-Net SD Advanced Configuration

Revision 06.k

Student Guide

Acme Packet Inc.

100 Crosby Drive
Bedford, MA 01720 USA
t 781 328 4400
f 781 425 5077
www.acmepacket.com
© 2012 Acme Packet, Inc. All rights reserved. Acme Packet, Session-Aware Networking, Net-Net and related
marks are trademarks of Acme Packet. All other brand names are trademarks or registered trademarks of
their respective companies.

The content in this document is for informational purposes only and is subject to change by Acme Packet
without notice. While reasonable efforts have been made in the preparation of this publication to assure its
accuracy, Acme Packet assumes no liability resulting from technical or editorial errors or omissions, or for
any damages resulting from the use of this information. Unless specifically included in a written agreement
with Acme Packet, Acme Packet has no obligation to develop or deliver any future release or upgrade or any
feature, enhancement or function.

Acme Packet Net-Net products are protected by one or more of the following patents:
United States: 7072303, 7028092, 7002973, 7133923, 7031311, 7142532, 7151781.
France: 1342348, 1289225, 1280297, 1341345, 1347621.
Germany: 1342348, 1289225, 1280297, 1341345, 1347621.
United Kingdom: 1342348, 1289225, 1280297, 1341345, 1347621.
Other patents are pending.

ii  Net-Net SD Advanced Configuration Copyright © 2012 Acme Packet, Inc.

Course Overview

This course provides technical network professionals with the skills needed to successfully understand and
configure the Net-Net 4000 using advanced routing configuration models, advanced SIP manipulations using
regular expressions and different ways of handling media. This course covers the fundamentals of DNS and
ENUM, different use of the Net-Net SD as B2BUA or Stateful or stateless Proxy (Session Router), as well as
a basic explanation of the principals of regex, needed for the optimal configuration of the Net-Net 4000
series. It also gives pros and cons for most of the options together with many case studies taken from
lessons learned and real implementations.

This course consists of lecture, discussion (around 40%) and significant hands-on labs (around 60%).

Intended Audience
This course is intended for individuals who will be responsible for hands-on configuration tasks or designing
complex solutions with the Acme Packet Net-Net 4000 series running Net-Net OS version 6.x, increasing the
flexibility and performance of those solutions.

Prerequisites

The Net-Net 4000 Configuration Basics class and experience configuring the Net-Net Session Director are
important prerequisites to the Advanced Configuration class. This course jumps right into advanced topics
and students will not get the most out of this class if they haven't met these prerequisites.

Course Agenda
 Module 0 [intr]- Course Overview
o This module introduces students to the course contents and objectives

 Module 1 [advr]: Advanced Routing

o Student leaning objectives include:
o Understand Net-Net SD routing options
o Management Routing
o ALG and static-flows
o Student performance objectives include:
o Configure and verify management routing

 Module 2 [adr]: Advanced Dynamic Routing (DNS, ENUM, LRT)

o Student leaning objectives include:
o Understand DNS theoretical aspects
o Understand DNS configuration on the Net-Net SD
o Understand ENUM theoretical aspects
o Understand ENUM Configuration on the Net-Net SD
o Describe Local Routing Tables (LRT) on the Net-Net SD
o Student performance objectives include:
o Configure the Net-Net SD to route using LRT
o Configure the Net-Net SD to use Multi-stage routing

Copyright © 2012 Acme Packet, Inc. Net-Net SD Advanced Configuration  iii

  Module 3 [asr]: Advanced Session Router
o Student leaning objectives include:
o Understand Traditional Class 4 networks
o Be able to explain what is OSR (Open Session Routing)
o Configure a Session Router as Session-Stateful, Transaction-stateful or
Transaction-stateless
o Enumerate the advantages over Net-Net Session Director
o Student performance objectives include:
o Configure and verify OSR operation with a Session Router

 Module 4 [abt]: Advanced Business Trunking

o Student leaning objectives include:
o Understand the Business trunking principles and options
o SBC applications: Straight-through trunking, Sip connect, Trunk group URI and
Surrogate registrations
o Student performance objectives include:
o Configure the Net-Net SD’s trunk-group and trunk-context routing

 Module 5 [ahmr]: Advanced Header Manipulation Rules

o Student leaning objectives include:
o HMR rule set basics
o How HMRs are constructed and processed by the Net-Net SD
o Regular expression (regex)
o The use of regex within HMRs
o New features in Cx6.X (Mime and ISUP rules, system variables, etc)
o Student performance objectives include:
o Configure complex SIP manipulation rules (without regex)
o Use Regex Coach to create regular expressions
o Configure SIP manipulation rules using regex

 Module 6 [admh] – Advanced Media Handling

o Student leaning objectives include:
o How media flows are handled by the Net-Net Session Director (SD)
o Access controls for media
o Latching, symmetric-latching and restricted-latching
o Bandwidth CAC and media traffic shaping
o Traffic policing for media
o QoS management
o Codec policing
o Student performance objectives include:
o Verify media management
o Configure symmetric latching
o Configure media access controls
o Configure bandwidth CAC and verify traffic shaping
o Configure QoS settings
o Verify QoS reporting in CDRs
o Configure codec policies

iv  Net-Net SD Advanced Configuration Copyright © 2012 Acme Packet, Inc.

Document Conventions
The following table lists the syntax-related style conventions used throughout this document:

Style Description Usage Example

Arial Lab instructions and descriptive text. Enter Superuser mode and determine what
commands are available in this mode.
Courier New Acme command line interface out-put. The system prompt for User mode is
training>.
Courier New Bold Acme command line interface input. Use the show ? command to determine
which show commands are available in
User mode.

Additional Information
Training Offerings
You can obtain information on the latest training offerings, course dates, and class locations from the World
Wide Web by pointing your Web browser to: www.acmepacket.com/training.

Certification Program
You can obtain information on the Acme Packet Technical Certification Program from the World Wide Web
by pointing your Web browser to: www.acmepacket.com/certification.

About This Publication

This document is written and maintained by Acme Packet Training Department. Please email questions and
suggestions for improvement to [email protected].

Technical Publications
Acme Packet is committed to providing our customers with reliable technical documentation.

The Acme Packet Documentation Set is currently available on CD, via our customer portal or on our support
website.
 One Acme Packet Documentation Set CD and one Acme Packet Hardware Installation guide is
included in the accessory kit that is shipped with each Net-Net system.
 Customers can also access the Acme Packet Documentation Set via the customer portal. To
access technical documentation via the customer portal you must contact your Acme Packet
customer support representative directly or email [email protected] to obtain a login.

Acme Packet Support

Please contact your Acme Packet customer support representative directly or email
[email protected] if:
 You need technical product support.
 You have any questions, comments, or suggestions regarding our product documentation.
 You would like to request additional Acme Packet documentation CDs.
 You have trouble accessing the documentation through the Acme Packet secure FTP server.

Copyright © 2012 Acme Packet, Inc. Net-Net SD Advanced Configuration  v

vi  Net-Net SD Advanced Configuration Copyright © 2012 Acme Packet, Inc.
advr.6.j.pm-0
Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-1

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-2

Advanced Routing on the Net-Net SD

Session Routing in the Net-Net OS Architecture

Session routing is a key element of the Net-Net Operating System (OS) session
control subsystem. The subsystem is designed to route VoIP connections using
a variety of criteria. The following slides describe some protocols and
mechanisms the Net-Net SD uses to specify a route, many of which rely on the
Net-Net SD’s Local Policy configuration element. Key members of this list
include:
• Domain Name Server (DNS)
• Electronic Numbering (ENUM)
• Local Routing Tables (LRT)
• Load Balancing
The following slides describe these protocols and mechanisms as well as
provides some introductory information about how to configure them.
There are also advanced mechanisms that do not use local policies to route
traffic, for example business trunking which is described in its own topic after
local policy-based routing.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-3

Advanced Routing on the Net-Net SD

What Happens Before Routing Decisions are Made?

The order the Net-Net SD uses to perform packet processing provides
important insight into how configuration elements affect routing decisions.
For example, the Net-Net SD validates ingress messages, a process called
parsing, before allowing a packet to proceed through the system. After this
validation, the Net-Net SD applies inbound header manipulations that actually
change packets before they even reach the routing subsystem.
You then configure the Net-Net SD to use the results of both this validation and
header manipulation to affect the routing decision.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-4

Advanced Routing on the Net-Net SD

Routing Options
A Session Border Controller (SBC) uses signaling information to make routing
decisions. This differentiates it from switches and routers. This paradigm
extends upon the logic of separating the overhead of MAC and IP forwarding
between switches and routers. Keeping an application’s routing decision
separate from work conducted by lower layer equipment allows each device to
focus on its own complex task: The switch forwards based on MAC; the router
routes based on IP; the SBC routes based on VoIP signaling protocol
information.
Configuring the Net-Net SD, Acme Packet’s SBC, to perform application-
specific routing and apply application-specific controls provides you with better
processing of and a clean demarcation between each layer’s function. Each
function is handled with better performance, efficiency, precision and accuracy.
Within the context of precision and accuracy, the Net-Net SD is extremely
flexible in the way it allows you to define routes. Routing can be based on an
array of criteria ranging from simple local policies to complicated LRTs.

The following are the key session routing mechanisms on the Net-Net SD:
Local policy— This is an extremely flexible configuration element that is used
as the base for many routing methods.
ENUM and LRT (local Routing Tables)— These functions are used in
conjunction with local policies to convert E.164 numbers into URIs.
Trunk-group URI— This method consolidates routing requirements into a
single configuration element. The Net-Net SD routes by reading the tgrp and
trunk-context headers from the Request-URI and finding a matching
destination, often a Session Agent (SA) or Session Agent Group (SAG).

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-5

Advanced Routing on the Net-Net SD

Routing Options (cont’d)

Registration Cached DB— This method provides routing from the core back to
access environments without requiring routing tables. It is often used in conjunction
with HNT mechanisms.
Request-URI hostname resolution— With this method, the Net-Net SD uses the
Fully Qualified Domain Name (FQDN) from the Request-URI to perform a DNS
query and learn the next hop. In this environment, the Net-Net SD behaves as a
standard Proxy.
Route Header and maddr— With this method the Net-Net SD searches for
specified headers that may be present in the SIP method. If found, the Net-Net SD
makes a routing decision based on these headers.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-6

Advanced Routing on the Net-Net SD

Routing Options (cont’d)

Static 1:1 mapping— Also referred to as SIP-NAT Bridging, this model is the
most common 1:1 route mapping configuration element. Note that while SIP-
NATs are highly reliable, they are also resource intensive.
H.323 B2BGK or B2BGW— As an H.323 B2BGK, the Net-Net SD works with
LRQ and LCF for requesting and receiving the next hop information; as an
H.323 B2BGW, Net-Net SD works with ARQ and ACF. In access scenarios,
the Net-Net SD can also include a registration cache of terminals or GWs.
Application Layer Gateway (ALG)— A static configuration element used for
NATting source and destination messages from MGCP, NCS, or H.248.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-7

Advanced Routing on the Net-Net SD

Local Policy, the Preferred Routing Engine

Local policies indicate where session request messages, such as SIP INVITES,
are routed and/or forwarded. You use a local policy to set preference for
selecting one route over another.
When you configure session routing for SIP and H.323, you can use SAs,
SAGs, and local policies to define routing. Using SAs and SAGs is not required
because an IP address or FQDN can be used. However using SAs increases
flexibility and security.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-8

Advanced Routing on the Net-Net SD

Local Policy Parameters

Local policies contain the following details that affect the routing of SIP and
H.323 signaling messages:
Information in the From header and Request-URI — Information in the
message’s From header is matched against the entries in the local policy’s
from-address parameter to determine if the local policy applies. The Request-
URI is matched against the to-address.
List of configured realms — This list identifies the source realm of the traffic.
The Net-Net SD performs routing based on that ingress realm. The source
realms identified in the list must correspond to the valid realm IDs you have
already configured.
Local policy attributes — These configurable attributes serve as an
expression of preference, a means of selecting one route over another. They
contain information such as the next signaling address to use (next hop) or
whether to select the next hop by codec, or next hop realm. They can also
specify the application protocol to use when sending a message to the next
hop. In addition, these attributes are used to filter specific types of traffic.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-9

Advanced Routing on the Net-Net SD

Ingress Realm Determination

In order to make the appropriate decisions for an incoming request the
source, or ingress, realm needs to be determined. The Net-Net SD may
go through 4 steps:
1.The request comes through a specific Network Interface (slot,
port and VLAN). If there is only one realm bound to this Network
Interface the process is complete. However, the Net-Net SD
supports Overlapping IP (OLIP) by allowing more than one
realm to be bound to the same Network-Interface. In this case –
2. The Net-Net SD looks at the source IP address and compares
it with the list of configured Session Agents’ IP addresses. If
there is a match, the Net-Net SD takes the realm of the
matching SA as the ingress realm. Otherwise –
3. The Net-Net SD looks at the packet’s ingress sip-port/sip-
interface (i.e. destination address of the flow). A SIP interface is
attached to a realm, so the process is complete, unless we have
a case where nested realms share the same SIP-Interface. In
this case –
4. The Net-Net SD looks at the source IP address and compares
it with the addr-prefix parameter of all the realms. A match will
finally determine the ingress realm.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-10

Advanced Routing on the Net-Net SD

Policy-Attributes Parameters for Local Policies

The Local Policy a list of possible routes based on the source realm, the from-
address (from-URI), and to-address (Request-URI). This list (of “policy-
attributes” elements) is then used to select the destination for the session. For
example, if a “policy-attributes” element falls outside of the configured time/day
it will not be selected and the next element will be tested. Similarly, a policy-
attributes element will not be used if carriers are configured and the SIP
requests have a Carrier header that does not match.

start-time & end-time— Define the time-window (within the day) during which
this policy-attributes element should be considered. Use 4-digit military format
e.g. “1730”.
days-of-week — Enter any combination of days of the week (plus holidays)
you want the local policy attributes to be considered as the days-of-week
parameter value. You must enter at least one day or holiday here. A holiday
entry must correspond with a configured holiday in the session-router element.
Available values include: U (Sunday), M (Monday), T (Tuesday), W
(Wednesday), R (Thursday), F (Friday), S (Saturday), and H (Holiday). You can
enter a range of values separated by a hyphen, i.e. U-S and you can enter
multiple values separated by commas, for example M,W,F. Do not use spaces.
media-profiles — Configure a list of media profiles if you want the local policy
to route SIP and H.323 traffic by the CODECs specified in the Session
Description Protocol (SDP). The list of media profiles entered here are matched
against the SDP included in SIP or H.323 requests and the next hop is selected
by codec. The values in this list are matched against the rtpmap attribute of
passed SDP, and preference weight for route selection is based on the order in
which the matching payload type appears in the SDP’s media line (m=).
cost — Enter a number representing a relative route’s cost. This will determine
the preferred route among possible routes to the same destination (TO
address). This value can be viewed as a way of ranking policy attributes. If cost
is not specified the Net-Net SD will attempt to use routes in the order they were
configured.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-11

Advanced Routing on the Net-Net SD

Policy-Attributes Parameters for Local Policies

realm— Identifies the egress realm (the realm used to reach the next
hop) if the Net-Net SD must send requests out from a specific realm.
The value must be a valid realm identifier. If you do not enter a value,
and the next hop is a Session Agent, the realm identified in the SA
configuration is used for the next hop. In H.323, the next hop address is
matched against the realm’s address prefix to determine the egress
realm. The egress realm not only defines the outgoing network interface
and physical slot/port, but also the source signaling/media interface that
will originate the session
next-hop— Identifies the next signaling host. Possible values:
• A specific endpoint’s IP address,
• Hostname or IP address of a configured Session Agent (most
common),
• Group name of a configured SAG (where load balancing is
applied),
• enum_group - defines ENUM queries destination
• lrt_config - defines an XML file to be used in lieu of sending
out ENUM quries
• ldap_config - defines an external directory server (LDAP) for
used for resolving FQDNs
• 0.0.0.0 address.
The last selection creates a null route. Rather than not configuring a
policy-attributes element (which would trigger the Net-Net SD local
policy recursion), this terminates local policy recursion and immediately
fails the request. In these cases, the Net-Net SD responds to the
request with a 404 Not Found.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-12

Advanced Routing on the Net-Net SD

Session Agents Constraints

The 5 constraints discussed on the slide cause the Net-Net SD to suspend the
routing of traffic to a SA. Valid SIP SAs include the following:
• Softswitches
• SIP proxies
• application servers
• SIP gateways
• SIP endpoints
In addition to functioning as a single logical next hop for a signaling message
(for example, where a SIP INVITE is forwarded), SAs can provide information
about next or previous hops for packets in a SIP agent, including providing a list
of equivalent next hops. You can use the SA to describe one or more SIP next
or previous hops. This set of carriers will be matched against the local policy for
requests coming from the SA. You can also set constraints for specific hops.
The Net-Net SD monitors availability, session load, and session rate for each
SA in real time. The SA’s state is determined by its performance relative to the
constraints applied to it and its availability.
Some of the reasons the Net-Net SD will mark an SA out of service include:
maximum sessions exceeded, maximum outbound sessions exceeded,
maximum burst rate exceeded, maximum sustained rate exceeded, SA
unavailable or unresponsive.
The burst-rate-window and sustain-rate-window parameters can be
configured differently per Session Agent and measure the interval
window in seconds where the thresholds or maximum limits are going to
be applied.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-13

Advanced Routing on the Net-Net SD

Note that a value of 0 means there is no limit or the feature is disabled.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-13

Advanced Routing on the Net-Net SD

Message Throttling
You can configure throttling mechanisms for SIP INVITEs and REGISTERs
using session agent constraints. However, you might want to throttle other
types of SIP methods, and for those methods you should use the rate
constraints configuration available both in the session constraints (which you
then apply to a SIP interface or a realm) and the session agent configurations.
Acme Packet recommends you use session agent constraints for session-rate
INVITE throttling and registration-rate for REGISTER throttling.
You can configure separate constraints, setting inbound and outbound values
for burst and sustain rates, for each different method type you configure.
Although you should use session agent constraints (and not rate constraints)
for INVITEs, if you also set up rate constraints for INVITEs, then the smallest
configured value takes precedence.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-14

Advanced Routing on the Net-Net SD

Message Throttling (cont)

There are methods for which the rate has already been effectively throttled by
throttling the method that started the SIP transaction or the whole dialogue (e.g.
ACK or BYE). It is therefore not recommended to constrain these methods. Other
methods, such as OPTIONS, are good candidates for throttling.
Very useful troubleshooting information can be easily obtained when session-
router>sip-config>extra-method-stats is set to enabled

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-15

Advanced Routing on the Net-Net SD

Message Throttling Configuration

Each rate constraint you configure for a SIP method tracks its own counters.
For example, if you configure a rate constraint for the PUBLISH method, the
burst and sustain rates you set for it apply only to the PUBLISH method and not
to any other methods for which you might set up rate constraints. You can,
however, set the burst rate window in the session constraints configuration that
will apply to all methods configured as rate constraints.
The Net-Net SD captures statistics for SIP methods throttled by rate constraints
for SIP interfaces and session agents; it does not capture these statistics for the
global SIP configuration.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-16

Advanced Routing on the Net-Net SD

Session Agent Health Check

By sending ping messages, the Net-Net SD monitors session agents’ health
and can determine whether or not to take a session out of service (OOS), leave
it in service, or bring it back into service after being OOS.
The Net-Net SD determines session agents’ health by sending them ping
messages using a SIP method that you configure. Commonly, the method is an
OPTIONS request. If it receives any response from the session agent, then the
Net-Net SD deems that session agent available for use.
ping-method—SIP only. Indicate the SIP message/method to use to ping a
session agent. The ping confirms whether the session agent is in service. If this
field is left empty, no session agent will be pinged. Setting this field value to the
default OPTIONS method might produce a long response from certain session
agents and could potentially cause performance degradation on your Net-Net
SD.
ping-interval—SIP only. Indicate how often you want to ping a session agent
via the ping interval parameter. Enter the number of seconds you want the Net-
Net SD to wait between pings to this session agent. The default value is 0
(disables health check for the SA).
ping-in-service-response-codes—SIP only. Enter the list of response codes
to keep a session agent in service when they appear in its response to the Net-
Net SD’s ping request. The Net-Net SD takes the session agent out of service if
the response code to be used does not appear on this list. Default is none.
out-service-response-codes—SIP only. The list defines the response codes
that take a session agent out of service when they appear in its response to the
Net-Net SD’s ping request or any in-dialog creating request (such as an
INVITE, SUBSCRIBE, etc.). The Net-Net SD ignores this list if an in-service list
exists.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-17

Advanced Routing on the Net-Net SD

Load Balancing Sessions

You apply allocation strategies to select which of the SAs that belong to the
group should be used. For example, if you apply the hunt strategy, SAs are
selected in the order in which they are listed.
Hunt — The Net-Net SD selects the SAs in the order in which they are
configured in the SAG. If the first agent is available and has not exceeded any
defined constraints, all traffic is sent to the first agent. If the first agent is
unavailable, or is in violation of constraints, all traffic is sent to the second
agent. And so on for all SAs in the SAG. When the first agent returns to service,
the traffic is routed back to it.
Round Robin — The Net-Net SD selects each SA in the order in which it is
configured, routing a session to each SA in turn.
Least Busy — The Net-Net SD selects the SA with the least number of active
sessions, relative to the maximum outbound sessions or maximum sessions
constraints (lowest percent busy) of the SA.
Proportional distribution — SAs are loaded proportionately based upon the
respective maximum session constraint value configured for each SA.
Lowest sustained rate — The Net-Net SD routes traffic to the SA with the
lowest sustained session rate, based on observed sustained session rate.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-18

Advanced Routing on the Net-Net SD

Codec Based Routing

The Net-Net SD can route traffic based on the presence of a specific codec
within the SDP offer. You can configure this mechanism by setting a media-
profile in the policy attribute of a local policy. As the Net-Net SD parses through
the invite, it watches for this codec as an option.
Note that the Net-Net SD performs this routing regardless of where the option
appears in the list. This can cause unexpected results. Be careful to ensure that
the option is never present in offers that you don’t want routed by codec.
Note that this mechanism is for routing only, the Net-Net SD can also remove
and re-order CODECSs. The Net-Net 9000 series SBC can even perform
transcoding, but these functions are completely separate from the slide’s
media-profile based routing topic.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-19

Advanced Routing on the Net-Net SD

Route Header Handling on the Net-Net SD

Methods that include route header must follow its content as the destination for
this message. The Net-Net SD can also add this Route header and there are 2
ways to perform this:
Strict — Per RFC 2543, the Request-URI is destroyed. Although used as the
next hop, the egress message route header list has the original Request-URI.
Loose — Updated per RFC 3261, the Request-URI is kept separate from the
route header field, remaining unchanged. According to RFC 3261, a proxy is
loose routing if it follows the procedures defined in the specification for
processing of the route header field. These procedures separate the destination
of the request (present in the Request-URI) from the set of proxies that need to
be visited along the way (present in the route header field).
If we find that the next hop value of a local policy matches a Session Agent with
loose routing enabled (default value), then the next-hop is added as the top
route header. This is now the most common implementation
By stripping out the route headers, the Net-Net SD can help you defend against
tampering with the route header intended to force the method, such as an
invite, down the wrong path. This tampering can cause the method to, for
example, skip a softswitch enabling the hacker to avoid billing for calls.
In some cases, the next hop field value must replace the Request-URI in the
outgoing request, even if the original Request-URI is not the Net-Net SD. To
accomplish this, you configure the replace-uri parameter value in the local
policy. This causes the next hop value to be used as the Request-URI and
prevents the addition of route headers.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-20

Advanced Routing on the Net-Net SD

Redirect Routing
The re-direct option parameter in the sip-interface and SA
configurations defines how the Net-Net SD will respond to 3xx redirect
messages. When set to the default value of proxy, the Net-Net SD
sends the redirect response back to the previous hop. When set to
recurse, the Net-Net SD attempts to send the method, such as an
INVITE, to the contact or redirect destination. In this case a lookup will
be triggered again to select a route or list of routes, therefore adding
great routing flexibility (i.e. we can choose a different egress realm for
this redirected message). Note that the SA configuration takes
precedence over the sip-interface configuration.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-21

Advanced Routing on the Net-Net SD

Recursion in local policies and SAG

By default the Local policies try to find a list of alternate routes and if the first
fails they will continue trying in a sequential order. This order is determined
principally by the cost parameter in the policy attribute. To stop this behavior
you can enable a parameter called terminate-recursion. This stops the system
trying alternate routes and forces an error message back to the originator if the
destination fails. For this parameter you need the routing license in your Net-
Net SD.
You can configure a SIP session agent group (SAG) to try all of its session
agents rather than to the next-best local policy match if the first session agent in
the SAG fails. For that you need the Load Balancing license to be purchased
for the particular Net-Net SD.
When you enable SIP SAG recursion, the Net-Net SD will try the additional
session agents in the selected SAG if the previous session agent fails. You can
also set specific response codes in the SAG configuration that terminate the
recursion. This method of terminating recursion is similar to the Net-Net SD’s
ability to stop recursion for SIP interfaces and session agents.
You can also implement stop recursion for a list of configurable responses. You
do that in the Session Agent or the Sip-Interface with the parameter stop-
recurse, where you need to enter a list of returned response codes that this SIP
interface will watch for in order to stop recursion on the target’s or contact’s
messages. This list can be a comma-separated list of response codes or
response code ranges.
ACMEPACKET(sip-interface)# stop-recurse 404,484-486

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-22

Advanced Routing on the Net-Net SD

Routing Management Traffic

Host routes let you insert entries into the Net-Net SD's routing table. These
routes affect traffic that originates at the Net-Net SD’s host processor. Host
routes are used primarily for steering management traffic to the correct
network.
When traffic is destined for a network that is not explicitly defined on a Net-Net
SD, the default gateway configured in the system-config is used. If you try to
route traffic to a specific destination that is not accessible through the default
gateway, you need to add a host route. Host routes can be thought of as a
default gateway override.
Certain SIP configurations require that the default gateway be located on a front
media interface. In this scenario, if management applications are located on a
network connected to a rear-interface network, you must add a host route for
management connectivity.
Note also that when source-based routing is used, the default gateway must
exist on a front media interface. In this situation, host routes might again be
needed to reach management applications connected to a wancom/eth/mgt
port.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-23

Advanced Routing on the Net-Net SD

Host Route Configuration

To configure a host route, follow the steps below:
1. From Superuser mode, type configure terminal and press <Enter>.
ACMEPACKET# configure terminal
2. Type system and press <Enter> to access the system-level
configuration elements.
ACMEPACKET(configure)# system
3. Type host-route and press <Enter>. The system prompt changes to
let you know that you can begin configuring individual parameters.
ACMEPACKET(system)# host-route
ACMEPACKET(host-route)#
4. Set the following parameters to configure host routes:
Dest-network — Set the IPv4 address of the destination network towards
which the host route points.
Netmask — Set the netmask portion of the destination network for the route
you are creating. The netmask is in dotted decimal notation.
Gateway — Set the gateway that traffic destined for the address defined in the
first two elements should use as its first hop.
Issue a save-config and then activate-config. You do not need to
reboot your Net-Net SD to complete a host route change.
The three parameters above define a new entry into the routing table. For each
host route or routing exception you want to add you make a new entry with all
three of the above parameters.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-24

Advanced Routing on the Net-Net SD

Source Based Routing

When trying to reply to any management packet that arrives through the Media
Interfaces, the Host Subsystem (CPU) looks at the Routing table. This routing
table can be obtained by the command “show routes”. If we have several Media
Interfaces with the same range of IPs (we call this OLIP or Overlapping IPs),
then the CPU will take the first that was instantiated, and it might not be the one
the packet came through.
In order to resolve this issue, by enabling source based routing, we put a tag on
incoming management packets, to track the Slot, Port and VLAN this packet
came into, therefore replying to the same Media Interface and VLAN.
This feature will work as well for the Wancom0 or Mgt0 interface, resolving
routing issues if this network is in the same range as one or more Network-
Interfaces.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-25

Advanced Routing on the Net-Net SD

Source Based Routing Configuration

By default, this feature is disabled. To enable Source Based Routing, you must
set to enable the parameter source-routing under system-config.
Before Rls C5.X, this needed to be enabled by entering the flag value of
0x80008 in the boot parameter.
In any of the two cases, after enabling Source Based Routing the system must
Reboot as it is not an RTC
We assume for sure that in order to allow Management Traffic through this
Media Interfaces, the Network-Interface should be configured with HIPs and
Protocol IPs (ICMP, Telnet, SNMP or FTP)

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-26

Advanced Routing on the Net-Net SD

ICMP more flexible than ever

It is possible to support specific non-media related protocols on the front
interfaces (specifically, ftp, icmp, snmp and telnet). This is not
recommended in production networks as it may present a security risk.
This is done by adding an ftp, icmp, snmp and/or telnet address to the
network interface. Only one address is allowed per protocol, except for
ICMP where you can specify a list. The reason for allowing a list for
ICMP is to be able to answer to health checks from remote devices if
they do not support any other more intelligent method like SIP Options.
The addresses may be the same or different from the one bound to the
network interface, as long as they are in the same subnet.
The generalized form of the command to add this functionality is add-
<protocol>-ip. For example, specifying add-ftp-ip 192.168.0.11 binds
this IP address for FTP service on this network interface. Conversely,
to remove this binding, issue the remove-<protocol>-ip command.
An entry must be made in the HIP (host in path) List for these bound
addresses. This indicates to the Net-Net SD to allow access to
signaling and maintenance protocol stacks via front interfaces using the
HIP feature. Entries are added by specifying the add-hip-ip command
and removed with the remove-hip-ip command.
On activation of the configuration, the SD will send a gratuitous ARP
message for each address indicated in the HIP list.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-27

Advanced Routing on the Net-Net SD

In the ping command from the Net-Net SD you can now specify the egress
Network-Interface as well as the source-ip. This increases the flexibility and
allows you to better troubleshoot Layer 2 or Layer 3 connectivity issues.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-27

Advanced Routing on the Net-Net SD

Application Layer Gateway

Static flows allow network traffic that matches specific criteria to pass through
the Net-Net SD unrestricted. This feature lets you steer traffic toward a
particular destination based on its original characteristics. Static flows can
range from being widely accessible to very restrictive, depending on the values
you establish. Static flows are used for transporting a variety of signaling
messages through the Net-Net SD to achieve vendor interoperability.
The Net-Net SD supports Network Address and Port Translation (NAPT) and
Trivial File Transfer Protocol (TFTP) functionality over media interfaces,
collectively known as Network Address Translation (NAT) ALG. The NAT ALG
feature is implemented as an extension of the static flow feature.
In some applications, the Net-Net SD acts as an intermediary device,
positioned between endpoints located in an access network and application
servers located in a backbone network. The Net-Net SD’s NAT ALG feature
enables these endpoints to use non-VoIP protocols, such as TFTP and HTTP,
to access servers in a provider’s backbone network to obtain configuration
information.
NAT ALG parameters support RTC and can be dynamically reconfigured. The
active NAT ALG configuration can be replicated on the standby SD in an HA
configuration.
The TFTP ALG is implemented as an extension of the NAT ALG. It works
slightly differently from traditional NAPT. In a TFTP session, the first packet is
sent from a source endpoint to port 69 on the TFTP server. The TFTP server
responds from another port. This port, from which the TFTP response
originates, is used for the remainder of the TFTP session.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-28

Advanced Routing on the Net-Net SD

Static-flow
The static flow element explicitly writes entries into the CAM and the IP routing
table. These entries are persistent and are not deleted as calls are set up and
broken down.
A static flow entry watches for traffic with specific criteria on a specified ingress
realm; that traffic consists of the following criteria:
1. The IPv4 packet enters the Net-Net SBC on the specified ingress
realm.
2. The packet contains matching source address, subnet, and port
criteria, field 1.
3. The packet contains matching destination address, subnet, and port
criteria, field 2.
4. The packet contains a matching transport protocol, field 3.
If the above conditions are met, then the Net-Net SBC does the following:
1. The IPv4 traffic is forwarded out of the Net-Net SBC on the specified
egress realm.
2. The configured source address, subnet, and port criteria are written
to the exiting packet, field 4.
3. The configured destination address, subnet, and port criteria are
written to the exiting packet, field 5.
4. The original transport protocol and its contents remain unchanged as
the packet exits into the egress realm.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-29

Advanced Routing on the Net-Net SD

Topic Review: Net-Net SD routing options

• How do we perform codec based routing?
By setting the media-profile on the policy-attribute.

• State the four steps performed by the Net-Net SD to select ingress realm:
1) port/slot and VLAN; 2) Source IP = SA; 3) Destination IP = Sip-
Interface; 4) Source IP = address-prefix.

• What Default gateway does the Net-Net SD use for management traffic?
Can we configure different ones?
It uses the System-config Default-gateway and to modify this we need
to configure host-routes.

• Explain two of the recommended options to be configured in Advanced SIP

Access scenarios to be more resilient
Temporary promotion, refresh REGISTER instead of reject, increase
exp in access, maximum REGISTERs to core and Cache grace-timer
configuration

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-30

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-31

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-32

advr.6.j.pm-0
Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-1

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-2

Advanced Routing on the Net-Net SD

DNS Basics
The Domain Name System (DNS) is a distributed Internet directory service.
DNS is used mostly to translate between domain names and IP addresses and
to control email delivery. Most Internet services rely on DNS to work. If DNS
fails or is too slow, web sites cannot be located and email delivery is delayed.
The DNS system consists of three components:
• DNS data (called resource records)
• Servers (called name servers)
• Internet protocols for fetching data from the servers
The billions of resource records in the DNS are split into millions of files called
zones. Zones are kept on authoritative servers distributed all over the Internet,
which answer queries based on copies of resource records stored in the zones.
Caching servers ask other servers for information and cache any replies. Most
name servers are authoritative for some zones and perform a caching function
for all other DNS information. Large name servers are often authoritative for
tens of thousands of zones, but most name servers are authoritative for just a
few zones.
A recursive query causes the DNS server to fully answer the query or give an
error. Authoritative responses are NOT recursive queries.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-3

Advanced Routing on the Net-Net SD

DNS Queries
SIP uses DNS procedures to resolve SIP Uniform Resource Identifier (URI) into
the required IP address, port, transport and protocol. Using DNS, it possible to
balance SIP servers and provide fault tolerant SIP service. This is because
DNS allows clients to send a request to a backup server if the primary has
failed.
DNS service is known as a service for providing a way of mapping Internet
domain names into IP numbers. Domain names are easy to remember, but IP
addresses are required for connection setup. Modern DNS systems provide
more comprehensive services and allow the resolution of several IP addresses
to a single domain name as well as provide additional functionality on the types
of service available at a particular server. Extended functionality is provided by
means of new DNS request types, described below and in the following slide.
NAPTR
The Naming Authority Pointer (NAPTR) is the DNS resource record that
specifies a regular expression based rewrite rule that, when applied to an
existing string, produces a new domain label or Uniform Resource Identifier
(URI). Basically, it provides resolution to the type of service and transport being
used by a particular domain.
The Service (SRV) queries allow administrators to use several servers for a
single domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as backups.
Clients ask for a specific service/protocol for a specific domain and receive
back the names of any available servers. In order to make an SRV query, the
domain name service types and protocol should be known. SRV initial domain
name looks like _Service._Proto.Name. It can be either constructed manually
or be the result of a previous NAPTR query. Example: querying
“_sip._tcp.acme.com”

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-4

Advanced Routing on the Net-Net SD

NAPTR Query and SRV Query

The most significant fields in a NAPTR query are “service” and “regexp/replacement”.
“service”— Specifies the service(s) available down this rewrite path; it contains the
protocol name and, optionally, a list of resolution services. For the sip protocol, only SIP
and SIPS protocol constants are available. SIP would be used for ordinal
communication and SIPS would be used for secured communication. For protocol, D2T
resolution service is decoded as TCP and D2U as UDP service. The three records from
the example above represent TLS over TCP, TCP, and UDP services.
“regexp” and “replacement”— Used for getting the next domain name for lookup.
Replacement contains the exact next name, while regexp contains a regular expression
that is applied on the initial domain name. In both cases, the outcome is the same – the
next domain name for lookup becomes evident.
“Flags”— Specifies the type of next request to be applied to the resolved domain
name. Based on the example above, the next request should be an SRV request
because the flag name equals to “s”. Other available requests are “A” and “NAPTR”.
“Order” and “Prefs”—Used to establish the proper order of the NAPTR query result, in
terms of processing and best domain name selection for the next lookup.
An SRV query indicates that the domain for example, “acme.com”, using TCP transport
on SIP protocol can be accessed on server1.acme.com port 5060 or on
server2.acme.com port 5060. The SRV record fields include:
“Priority”— This field specifies the priority for server access. Servers with lowest
priority should be accessed first; backup servers usually have a larger priority and
should be used if servers with lower priority are not available.
“Weight”— This field is used if there at least two servers with the same priority.
Servers with a higher weight are more likely to be selected.
“Port” & “Target”— “Target” resolved with DNS “A” request into IP address; IP
address and port are used for connections establishment.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-5

Advanced Routing on the Net-Net SD

A Query
The DNS request type known as “A” Query is used for domain to IP address
mapping. When a domain name is resolved by an SRV request, the specific
element in the domain is returned. If the SRV is not available, multiple IP
addresses may be returned.
The process of locating a SIP server via server location discovery is described
in detail in RFC 3263. SIP server location discovery requires that the initial
domain name should usually be taken from the URI. i.e. the URI
[email protected] requires the resolution of the domain name “acme.com”.
This resolution requires several steps, including:
1. The DNS server checks to see if that the domain name passed for
resolution is not an IP address. If it is, the server should return the
IP address using the default settings for transport and protocol.
2. If the requester cannot strictly define the transport and protocol,
then the requester sends an NAPTR query. From the results of the
NAPTR query, the requester selects the record that best matches
the initial conditions. The requester then issues either a follow-up A
or SRV query.
3. If the requester knows the transport and protocol either initially or
via the results of a NAPTR request, it creates and posts a SRV to
DNS. For each record for the target name, the elements perform
further “A” resolution.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-6

Advanced Routing on the Net-Net SD

DNS and the Net-Net SD

There are several cases where the Net-Net SD needs to find the IP address to
send methods having only an FQDN or URI with domain name. In these cases,
the Net-Net SD needs to know which network-interface to launch the query
from and which DNS servers to launch the query towards. First, the system
determines the egress realm for the session. Then the system determines the
network-interface associated with this realm. Inside this element are 3
parameters related to DNS Servers, dns-ip-primary, dns-ip-backup1, and dns-
ip-backup2. These are the targets for the DNS query.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-7

Advanced Routing on the Net-Net SD

DNS Flexibility
The configuration explained in the previous slide is the default DNS lookup
behavior which you can modify by editing the configuration. When you set the
dns-realm parameter inside the egress realm to point to a different realm, the
query is originated from the network-interface of this dns-realm using its target
DNS servers. This provides flexibility and avoids the need to synchronize DNS
servers in different networks.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-8

Advanced Routing on the Net-Net SD

DNS Realm Configuration

This example on the slide shows how the system follows the different
configuration elements in order to find source and destination of the DNS
queries. It involves the local policy or, if the routing method is different, a way
to determine the egress realm for the session. Then the query refers to the
realm configuration to see the link with the network-interface and, if it is desired,
to change the default behavior of the dns-realm parameter. The last one is the
Network-interface itself were you define the DNS servers IP addresses.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-9

Advanced Routing on the Net-Net SD

What is ENUM?
ENUM is a standard protocol that supports the mapping of Internet services and
telephone numbers. The Net-Net SD can use ENUM as a basis for routing
decisions. ENUM was developed to allow network elements from traditional
telephony networks to find services on the Internet (mainly VoIP services) using
only a telephone number. It also defines how telephones, which have an input
mechanism limited to twelve keys on a keypad (no letters or signs like @ or .),
can be used to access Internet services like SIP endpoints.
ENUM has multiple meanings. It is a protocol that resolves fully qualified
telephone numbers (Formally called E.164) to fully qualified domain name
(FQDN) addresses using a DNS-based architecture. It is also the name of a
working group of the Internet Engineering Task Force (IETF) chartered to
develop protocols that map telephone numbers to resources found on the
Internet using DNS. It is also the title of RFC 2916, depreciated by 3761.
The main advantage of this protocol is that ENUM does not change the
numbering plan and does not change telephony numbering or its administration
in any way. It is entirely compatible with existing telephone network
deployments. ENUM does not drain already scarce numbering resources
because it uses existing numbers.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-10

Advanced Routing on the Net-Net SD

How ENUM works

ENUM works on SBCs as well as other devices, including PCs, PBXs and
gateways. It works in conjunction with ENUM servers deployed across the
network to manage phone number to IP service mappings.
For example, when a user types the telephone number in his web browser or
ENUM-enabled agent and indicates what item of information he is looking for
(email address, telephone number, web address, etc.) the number is reversed,
has its digits separated by periods, and is converted to a domain name. This is
sent to ENUM servers on the Internet, which sends back the NAPTR records
associated with the name. The access information and any priority indicated for
these resources are stored in the ENUM servers. This simple scenario can
quickly become complicated by the use of multiple queries from different users
and connections by a VoIP network to the PSTN. It is within the context of
these complex scenarios that the Net-Net SD comes to play a significant role.
Like DNS, there are significant security concerns related to ENUM servers. If
the ENUM server can be accessed by user devices in an untrusted network, it
can be the target of a direct attack. The Net-Net SD can secure an ENUM
server against such attacks, just as it can for other infrastructure elements.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-11

Advanced Routing on the Net-Net SD

ENUM and the Net-Net SD

ENUM enables Internet based users to make a selection from a range of
services available for communicating with another person when the caller
knows and can only dial a telephone number through a telephone keypad.
ENUM allows users to access Internet based services, mainly VoIP services,
and resources from Internet-aware telephones. It also allows access between
ordinary telephones connected to media gateways or proxy services and other
Internet-connected devices where input is limited to numeric digits.
The Net-Net SD is in the border of the core VoIP network and the break-out to
the PSTN network. Implementing ENUM on the Net-Net SD increases the
service reach and routing capabilities of the network.
The flexibility of the configuration and the reliability of having alternative ways of
routing to a group of ENUM servers or even a failback mechanism for routing,
should one server fail, makes the Net-Net SD one of the best solutions for
interacting with the ENUM servers.
The Net-Net SD works within (VoIP) applications. The long-stated goal of the
VoIP industry is to make a phone call over the Internet be as easy and provide
the same quality as a regular PSTN phone call. By supporting ENUM, the Net-
Net SD enhances the ability of VoIP to meet those goals.
Note also that the positioning of the Net-Net SD, at the border of the network,
allows you to configure the Net-Net SD to secure your ENUM servers from
threats while meeting the requirements of enhanced reachability and routing
flexibility.
Additional applications that may utilize ENUM include Internet fax and instant
messaging. These applications are also supported by the implementation of
SBCs.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-12

Advanced Routing on the Net-Net SD

ENUM as Result of Local Policy

ENUM is a DNS based architecture and protocol [RFC 3761]. The specification
defines how an E.164 number is expressed as an FQDN in a specific Internet
Infrastructure domain defined for this purpose (e164.arpa). The addition of the
ENUM lookup capability to the Net-Net SD enables the Net-Net SD to transform
e.164 numbers to URIs during the process of routing (or redirecting) a call.
Can be used for a subset of routing cases
Example: perform ENUM only for +44 numbers, but route all others directly; or
only do ENUM for inbound calls but not outbound, etc.
Different ENUM servers can be used for different cases
Example: e164.arpa public ENUM lookup for outbound, private ENUM lookup
for +44 555, PSTN infrastructure for fault back, etc.
Can have next-best alternate routes for non numbers, ENUM lookup failures, or
failures to reach ENUM-derived next-hops
Example: non-number SIP-URI routes to proxy1, E.164 uses ENUM but if not
reachable then route to PSTN gateway

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-13

Advanced Routing on the Net-Net SD

ENUM as Result of Local Policy (continued)

Can perform 305 redirects with ENUM results for subset of match cases (action
redirect in policy-attribute)
Example: for requests from app servers respond with redirect, but for requests
from peers handle as b2bua or proxy
Can have exception routes but with ENUM as the default
Example: 112 or 911 goes to EMERGENCY handling, video calls go to app-
server xyz, but everything else does ENUM

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-14

Advanced Routing on the Net-Net SD

ENUM Number Conversion Procedure

Once a telephone number is entered, it is translated into an Internet address
using the following steps:
1. The phone number is translated into a fully qualified E.164 number
by adding the city (or area) and country code.
For example, 555-1234 dialed in Washington, DC becomes +1-202-
555-1234, where the "1" represents the North American country
code. The "+" indicates that the number is a fully qualified E.164
number.
2. All characters are removed except for the digits. Example:
12025551234
3. The order of the digits is reversed. Example: 43215552021
4. Dots are placed between each digit. Example: 4.3.2.1.5.5.5.2.0.2.1
5. The domain "e164.arpa" is appended to the end.
For Example, 4.3.2.1.5.5.5.2.0.2.1.e164.arpa

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-15

Advanced Routing on the Net-Net SD

Additional ENUM services

When the Net-Net SD launches a query, it may receive several NAPTR results.
If so, it attempts to forward using the results sequentially.
The Net-Net SD supports E2U+SIP and No routes for a user, indicating that the
user has been provisioned but it is not active.
Back-reference simplifies the ENUM Server table configuration. You can
configure the Net-Net SD to use back reference when there are different
telephone numbers sharing a domain and the user is always a telephone
number in the user-uri part. This means that you do not need to repeat or set up
multiple entries.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-16

Advanced Routing on the Net-Net SD

ENUM Query commands

Example 1:
SD# show enum cache-entry test +7817654321
Query-->
Q:NAPTR 1.2.3.4.5.6.7.1.8.7.e164.arpa.com ttl=3404
Answers-->
order=100 pref=10 "u" "E2U+sip"
“!^.*$!sip:[email protected]!"

Example 2:
SD# show enum cache-entry test 1.2.3.4.5.6.7.1.8.7.e164.arpa.com
Query-->
Q:NAPTR 1.2.3.4.5.6.7.1.8.7.e164.arpa.com ttl=3352
Answers-->
order=100 pref=10 "u" "E2U+sip"
"!^.*$!sip:[email protected]!"

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-17

Advanced Routing on the Net-Net SD

ENUM Lookup keys

This method adds functionality and flexibility to the ENUM implementation on
the Net-Net SD. It allows the Net-Net SD to make queries on any number from
any field that is in the request. First, it copies the number into the Request-URI
using inbound Header Manipulation Rule (HMR). Remember that inbound
HMR processing happens before routing decisions. You configure the local-
policy > next-hop to make the ENUM query using this parameter. For example:
Next-hop enum:<enum_group>;key=<param-name>
The Net-Net SD makes the query using the content of this parameter name.
This configuration allows you to route using a CIC (Customer Identifier Code) or
an RN (Route Number). This is often required by service providers.
An additional lookup key that can be used is: show enum lookup lrt =
[cache_record_key]. This command shows a specific local-
routing-table entry for your ENUM server.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-18

Advanced Routing on the Net-Net SD

How to Configure ENUM - ENUM-config

name— Enter a string that uniquely identifies this ENUM configuration. You
use this name in other areas of the Net-Net SD configuration to refer to this
ENUM configuration. For example, in the local policy attributes.
top-level-domain— Enter the domain extension to be used when querying the
ENUM servers for this configuration. For example, e164.arpa. The query name
is a concatenation of the number and the domain.
For example, if the number is +17813334444 and the domain is e164.arpa, the
query name would be 4.4.4.4.3.3.3.1.8.7.1.e164.arpa
realm-id— Enter realm to reach ENUM servers. Realm ID is used to determine
on which network interface to issue ENUM query.
enum-servers— Enter the list of ENUM servers (an ENUM server and
corresponding redundant servers) to be queried. Separate each server address
with a space and enclose the list within parentheses. The first server on this list
is the first one to be queried. If the query times out (including retransmissions)
without getting a response, the next server on the list is queried and so on.
timeout— Enter the total time in seconds that should elapse before a query
sent to a server (and its retransmissions) will time out. Detail on this timeout
and subsequent timers are described in future slides.
cache-inactivity-timer— Enter the time interval in seconds after which you
want cache entries created by ENUM requests deleted, if inactive for this
interval. If the cache entry gets a hit, the timer restarts, and the algorithm is
continued until the cache entry reaches its actual time to live. Setting this value
to zero disables caching. For optimal performance, set this to one hour. Rarely

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-19

Advanced Routing on the Net-Net SD

used cache entries are purged and frequently used entries are retained.
lookup-length— Specify length of the ENUM query, starting from the mist significant
digit. Valid range for this value is 1-255; default is 0.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-19

Advanced Routing on the Net-Net SD

ENUM Configuration – Local Policy

In the Local-policy next-hop parameter enter the name of the ENUM-group in
the format:
Next-hop enum:<enum-group-name>
This indicates the group of Enum servers to which the query must be sent.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-20

Advanced Routing on the Net-Net SD

Timeout Calculation
timeout — Enter the total time in seconds that should elapse before a query
sent to a server (and its retransmissions) will time out. If the first query times
out, the next server is queried and the same timeout is applied. This process
continues until all the servers in the list have timed out or until one of the
servers responds. The retransmission of ENUM queries is controlled by three
timers. These timers are derived from this timeout value and from underlying
logic that the minimum allowed retransmission interval should be 250
milliseconds and that the Net-Net SD should retransmit 3 times before timing
out to give the server a chance to respond.
• Init-timer is the initial retransmission interval. If a response to a
query is not received within this interval, the query is retransmitted.
To safeguard from performance degradation, the minimum value
allowed for this timer is 250 milliseconds.
• Max-timer is the maximum retransmission interval. The interval is
doubled after every retransmission. If the resulting retransmission
interval is greater than the value of max-timer, it is set to the max-
timer value.
• Expire-timer is the query expiration timer. If a response is not
received for a query and its retransmissions within this interval, the
server will be considered non-responsive and the next server in the
list will be tried.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-21

Advanced Routing on the Net-Net SD

Testing ENUM queries

It is possible to test whether a certain query is going to work either from the
remote ENUM group or even from the internal cache. The test can be done with
the E.164 number or with the NAPTR.
It is also possible to clear the cache to force the next query and get to the
remote servers. The statistics shown on earlier slides help you analyze
performance regarding the use of ENUM servers.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-22

Advanced Routing on the Net-Net SD

Topic Review: DNS and ENUM

• How can the Net-Net SD choose the network for a DNS query?
By setting the parameter dns-realm on the egress realm.

• What is ENUM and when is it needed?

It is a method to convert e.164 numbers to URIs. It is needed to allow
telephone users to have internet services.

• Which protocol has been used as base for ENUM queries?

DNS

• Can the Net-Net SD cache the result of a query? Can we configure this
timer?
Yes it can and it is configured under enum-group element, cache-
inactivity-timer parameter.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-23

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-24

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-25

Advanced Routing on the Net-Net SD

LRT Theory
LRTs are a simple, flexible, and cheap way to emulate the services on an
external ENUM server without requiring any external request. You build the
tables in the NVRAM (/code/lrt) following a specific format. This file is
compressed using gzip to optimize space and allow the Net-Net SD to store
millions of routes.
LRT configuration for routing could be used for receiving calls from the PSTN
gateways (similar to ENUM) but also to route from inside the network to inside
or from inside to outside.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-26

Advanced Routing on the Net-Net SD

Principles of Local Routing Tables

A new task lrtd (local routing daemon) has been created to perform this
functionality. This task acts as an ENUM server. This task handles the ENUM
requests (NAPTR request) coming from the SIPD task and is responsible for
the ENUM lookup and sending the responses back to the sipd. This task is also
responsible for reading the “local-routing-config” objects, parsing the database
file (xml format) corresponding to each local-routing-config object, and storing
the route elements specified in the file in the local cache.
Local Routing functionality provides the Net-Net SD with the ability to do an
ENUM query for a SIP request to the lrtd (Local Routing Daemon). During the
routing of a SIP call, local policy attributes can be used to determine if a local
ENUM query is required, and if so, which Local ENUM server (local-routing-
config) needs to be queried. A successful local ENUM query results in a URI
that routes or redirects the call.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-27

Advanced Routing on the Net-Net SD

Sample XML File Contents

The xml file for the database should be in the following format:
<?xml version="1.0" encoding="UTF-8"?>
<localRoutes>
<route>
<user type="E164">666</username>
(reject this user with 604 does not exist anywhere)
<next type=“void">!^.*$!sip:[email protected]!</next>
</route>
<route>
<userName type="E164">1617</username>
<next type="regex">!^.*$!sip:[email protected]!</next>
</route>
</localRoutes>
Also this file should be stored at /code/lrt/ directory on the SD using the ftp
command. This file should be in the gzipped format.
The log files for the new task are log.lrtd and lrt.log (this will contain all the DNS
request and response communication between the sipd and the lrtd task.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-28

Advanced Routing on the Net-Net SD

LRT Configuration
To configure LRTs, you build a routing table using an xml template. Compress
this file (gzip) and copy it to /code/lrt into the Net-Net SD. Next, configure a
local-routing-config object pointing to the file and create a local policy with a
next-hop that points to the name of this object.
Use the command notify lrtd refresh <name> to update the local
cache corresponding to the local-routing-config. Use this command to update
the file with modifications to the entries. Substitute <name> with the name
parameter value in the local-routing-config element, used to identify the local
ENUM server.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-29

Advanced Routing on the Net-Net SD

local-routing-config Element Parameters

Access the local-routing-config object under session-router branch of the
configuration tree to configure your local ENUM server. Some of the
parameters in this configuration are mandatory.
The name of the element in the ACLI is local-routing-config. The XML tag is
LocalRouteConfig. The Local Routing Config object contains:
name – This string specifies the name of the local ENUM server. Match this
name to the local-policy policy-attribute next-hop. For example, if the local-
policy-attribute next hop is lrt: private_enum, the ENUM Lookup is performed in
the database according to the private_enum server config. This field is
mandatory.
file-name – Use this field to specify the file name in the local ENUM server that
contains the applicable routing entries. The file name should be in .gz format
and the corresponding file should be placed in the /code/lrt/ directory. This field
is also mandatory.
prefix-length – This element specifies the number of significant digits/bits
used for lookup and cache storage. This field is an unsigned integer. The
default value is set to 0.
string-lookup—Set this parameter to enabled for the Net-Net SBC to perform
LRT lookups on table keys of a string data type. Leave this parameter to its
default as disabled to continue using E.164 type lookups. This parameter is
present from Cx6.3 onwards.
match-mode—Set this parameter to either best, all, or leave it as exact which
is the default. This indicates to the Net-Net SD how to determine LRT lookup

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-30

Advanced Routing on the Net-Net SD

matches. This parameter is present from Cx6.3 onwards.

retarget-requests—Indicates if to replace with result of LRT the Request-URI in the
outgoing request or leave it as a Route header

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-30

Advanced Routing on the Net-Net SD

How to point to the LRT

The Net-Net SD uses the LRT when the next-hop parameter of the local-policy
policy-attribute points to it.
Next-hop lrt:<local-routing-config name>
Do not omit the lrt: prefix or the system may incorrectly refer to the name of a
SA.
The result of the internal query to the routing table is used as next-hop. If it is
an FQDN and does not contain an IP address, then an external DNS query may
be needed.
When action is set to redirect, the query sends a 302 answer back with the
result or results to the contact (acting as a redirect server). This configuration
option is used by many companies who sell ENUM service to other service
providers.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-31

Advanced Routing on the Net-Net SD

LRT SAG Matching

You can now also configure your Net-Net SD to match session agent group
(SAG) names with the hostname portion in the naming authority pointer
(NAPTR) from an ENUM query or LRT next-hop entry. When this feature is
enabled and the Net-Net SD finds a match, the Net-Net SD uses the matching
SAG for routing. When there is no match for the SAG, the Net-Net SD
processes the result as it would have if this feature had not been enabled:
either matching to a session agent hostname, or performing a DNS query to
resolve it.
To enable it you must go to sip-config and change the value of the parameter
enum-sag-match. Enter enabled if you want to match this SAG’s group name to
hostname portions of ENUM NAPTR or LRT replacement URIs. The default is
disabled.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-32

Advanced Routing on the Net-Net SD

LRT: Egress realm support

Including an egress realm in LRT result allows egress VPN to be selected to reach an
operator; enabling the SA to reside in the “*” realm
This resolves the lack of flexibility in interconnect routing
How it works –
New option, egress-realm-param, is added to sip-config and h323-config to
define URI parameter from which egress realm will be taken for both ENUM
and LRT results.
New options parameter format is: egress-realm-param=<name> where
<name> is parameter name to extract egress realm name from.
When egress-realm-param is defined, ENUM and LRT results will be checked
for presence of URI parameter. If URI does not contain parameter or parameter
identifies a realm that is not configured on system, egress realm that is
normally applicable (from local policy, SIP-NAT, or session-agent data) will be
used. sip-config options will apply for received SIP requests. h323-config option
will apply for received H.323 messages.
For example, if “egress” is egress-realm-param, then sip-config options will
contain: egress-realm-param=egress
And an entry in LRT that specifies egress realm “core” will look like this:
<route>
<user type="E164">+17815551212</user>
<next type="regex">!^.*$!sip:\[email protected];egress=core!</next>
</route>

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-33

Advanced Routing on the Net-Net SD

LRT Entry Matching

The ‘exact’ mode will only return entries from the table whose key value matches the
lookup key exactly. This is the current behavior of prior releases.
The ‘best’ mode will return an exact match if one exists in the table. Otherwise, it will
return the longest matching entry from the table where the key value from the table is a
prefix of the lookup key. For example, for the table below, a lookup key of 123456 would
return the ‘best’ match as entry # 4 (1234).
The ‘all’ mode will return any exact match as well as all partial matches where the table
entry’s key value is a prefix of the lookup key. For example, a lookup in the above table
with a key of 123456 would return entries 1, 3, and 4. Note that the ‘all’ mode will incur
a performance penalty because it must do multiple searches of the table (with
continually shortened lookup keys) to find all matching entries.

Entry# Key Result

1 1 <sip:\[email protected]>
2 122 <sip:\[email protected]>
3 123 <sip:\[email protected]>
4 1234 <sip:\[email protected]>
5 1234567 <sip:\[email protected]>
6 1235 <sip:\[email protected]>

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-34

Advanced Routing on the Net-Net SD

LRT: String lookup support

This option enables the possibility of performing routing for SIP URI user parts
containing alphanumeric strings and overcomes the problem of not being able to
perform route lookup for anything but E.164 numbers. This can be used both for service
provider and enterprise routing
How it works –
When string-lookup is disabled in Local Routing Configuration, lookup type
passed to LRT is E.164 unless eloc-str-lkup is enabled in the policy-attribute of
the local-policy, in which case, E-CSCF procedures are applied and the
resulting lookup type is ‘string’. Lookup type will also be ‘string’ (even with
string-lookup is disabled) when a compound key is specified. When string-
lookup is enabled in Local Routing Configuration, all lookups will be of type
‘string’. When lookup type is ‘E.164’, lookup is skipped if lookup key is not a
valid telephone number (i.e. it must contain only digits and visual separated,
any other characters are removed from key).

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-35

Advanced Routing on the Net-Net SD

Routing: LRT/ENUM lookup/query result SIP Route header support

Use loose routing for intermediary routes can be added to dynamic route lookups
Using embedded Route headers is new default behavior, but since it is unlikely that
existing ENUM or LRT tables contain embedded Route headers, it is expected that
there will not be a behavior change when existing SDs are upgraded. However, a sip-
config option (use-embedded-route) is being added to allow the new functionality to be
disabled just in case there are embedded Route headers in existing tables.
This new option will be added to sip-config for SIP calls and to iwf-config for H.323
originated IWF calls.
When ENUM or LRT result become the top Route header, any embedded Route
headers extracted are inserted just after that top Route (which will always be a loose
route and include the “lr” URI parameter). In this case, request will be sent to the top
Route. When ENUM or LRT results become Request-URI, any embedded Route
headers extracted from result are inserted before any Route headers already in the
outgoing request. Then if there are any Route headers in outgoing request and top
Route header has an “lr” URI parameter, request is sent to top Route header.
Otherwise, request is sent to the Request URI.
When retarget-requests is disabled (and the original Request-URI was not the SD
itself), the result URI from the LRT lookup will be added as the top Route header (along
with the “lr” URI parameter) and the Request-URI will remain unchanged. When
retarget-requests is enabled (or the original Request-URI is the SD itself), the result URI
from the LRT lookup will be used as the new Request-URI for the outgoing request.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-36

Advanced Routing on the Net-Net SD

Routing: Multiple key LRT lookup and ENUM query support

This feature allows more complex route lookups like source-based routing,
instead of having the route lookup limited to destination based routing
Enhancement allows for multiple, comma separated parameter and/or header
names to be specified with ‘key=’. For example, “key=$FROM,$TO” would
construct a compound key with user part of From URI followed by a comma
followed by the user part of the To URI.
If From were <sip:[email protected]> and To were
<sip:[email protected]>, resulting compound key would be “1234,5678”.
Note that for actual lookup in table, compound key is a single key value and
there is no special treatment of the comma in key matching. It is simply an
ordinary additional character that is matched like any letter or digit (i.e. the
comma must appear in the LRT entry’s “type” element data). For example, if
table was configured for “best” match-mode, lookup key “1234,5678” would
match a table entry of “1234,567”, but it would not match a table entry of
“123,5678”.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-37

Advanced Routing on the Net-Net SD

Topic Review: LRT (Local Routing Table)

• How is routing achieved in this configuration?
By accessing an internal file that contains e.164 to URI entries.

• Where and in which format is the translation file stored on the Net-Net SD?
It is copied in /code/lrt as name.xml.gz.

• What are the advantages and disadvantages of LRTs from the use of
external ENUM servers?
Advantages: Simple network configuration, cheaper, flexible.
Disadvantages: Not easy to update DB in operation, not centralized for
using it from many Net-Net SDs.

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-38

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-39

Advanced Routing on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. advr.6.j.pm-40

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-0
Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.i.pm-1

asrbt.6.j.pm-1
Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-2

Advanced Session Router And Business Trunking

Traditional VoIP architecture:

The smart core relies on the PSTN method of direct-connect between switching
devices. This was driven by the use of TDM circuits, but the difficulties in
provisioning TDM circuits also tempered the problem of excessive interconnect.
With VoIP, all devices are interconnected by the IP mesh, allowing direct
connections to many switches, but creating an impossible management and
security environment. This problem is typically referred to as the “N-squared”
problem of interconnecting N devices as each network needs its own switches
– there are almost N-squared (actually NxN-1) connections required.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-3
Advanced Session Router And Business Trunking

NGEN VoIP Architecture

In the smart border, data is a pooled resource. Interconnect borders are a point
of security and provide the grooming of reachability associations. Softswitch
dial plans become greatly simplified for both internal and external reachability.
Subscriber information is located in a shared database that may be queried
using standard interfaces.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-4
Advanced Session Router And Business Trunking

Stateless core, smart borders:

Smart borders – They provide security, protocol and address translations,
SLA assurance.
Stateless core – It will decide to which SBC the call will be routed by
accessing several Databases, thus allowing for pooling of resources
Best-of-breed, flexible routing databases –
Product, service or combination
ENUM (Electronic NUMbering) - IP connected endpoints that might need to be
called with an E.164 number from PSTN
LCR (Least Cost Routing) - most cost-effective PSTN termination
LNP (Local Number Portability)
CNAM (Calling NAMe)
Static policies – SR local route table
Dynamic policies – external routing database
Evolution – LPs (Local Policies) & LRTs (Local Routing Tables) to external
databases

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-5
Advanced Session Router And Business Trunking

Session Router, not a new hardware or software

As we will see later in this chapter, the Session Router product is not a new
hardware platform neither a new software load, it is just a different configuration
parameter value in sip-config to indicate that the Net-Net SD should act as a
Proxy (Transaction Stateful or Stateless). Most of the features are still valid
except those that require the entire session to be controlled by the Net-Net SD
like handling Media flows or CDR generation or QoS. When using other
features like sip-manipulations (HMRs), you need to keep into consideration
that some Transactions may go through the SR and others may not, therefore
this might limit the ability to apply certain modifications in the Headers, mainly
the ones intended for topology hiding.
The Session Router main task is to resolve a routing query and either forward
the session to this new destination or answer with a 3XX response giving the
new destination or destinations in the contact header.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-6
Advanced Session Router And Business Trunking

SIP Configuration
SIP-Config is a single instance element that provides global SIP controls for
the Net-Net SD.
Operation Mode
Dialog by default, it specifies the functionality of the entire Net-Net SD
handling SIP messages.
When set to dialog, the Net-Net SD will behave as a B2BUA, handling
sessions and breaking the dialogs. When set to session, the SD will behave
as a session stateful Proxy, handling the entire session, but maintaining a
single dialog before and after. In this mode it will never be able to handle
media flows. Those two modes of operation need a number of sessions in the
license.
A Session Router functionality will be achieved by setting the operation-mode
parameter to transaction (the SD will act as stateful proxy, keeping in memory
the state of the entire transaction) or to stateless (in this case it will not keep
in memory the state of the transaction). For those two modes of operation,
the Net-Net SD does not even need a session number as it does not handle
the entire session.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-7
Advanced Session Router And Business Trunking

SIP Message Flow Through the Net-Net SD as B2BUA

The slide shows a very basic, successful call flow from one User Agent Client
(UAC) to a User Agent Server (UAS) through the Net-Net SD. Note that all
signaling traverses the Net-Net SD, while not necessarily doing the same with
proxies in the path. All SIP messaging is targeted at a SIP interface’s SIP port to
egress the originating realm. All SIP messaging is originated from a SIP interface’s
SIP port when entering a realm.
Further, by default, media is steered through the Net-Net SD. All media exiting a
realm is targeted at the appropriate steering pool and all media entering a realm is
originated from the appropriate steering pool.
If we configure the Net-Net SD as Session Stateful, the call flow will look very
similar except that the media will never be anchored. The difference is inside the
Headers and the manipulation the Net-Net SD will perform as a B2BUA. The SD
does achieve topology hiding as it modifies the Contact, Via, Route (if present) and
Record-Route (if present) to its own IPs and will keep the original values in
memory to respect the flow.
By setting the operation-mode to Session Stateful, the SD keeps the original Via,
adds a new Via in the top on the egressing INVITE and will add two Record-Route
headers to indicate where the future transactions in the dialog need to be sent.

2012 Acme Packet, Inc.

Copyright © 2010 asrbt.6.j.pm-8
Advanced Session Router And Business Trunking

Basic SIP Message Flow with a Proxy

The slide shows a very basic call flow from one UAC to a UAS . In the example,
the UAC is a SIP-enabled phone and the UAS is a Net-Net SD acting as a proxy.
1. The UAC initiates the session with an INVITE to the SIP proxy (UAS).
2. The UAS sends a 100 Trying response back to the UAC indicating that the
request has been received and some unspecified action is being taken on
behalf of this call. This is the difference between Transaction Stateful and
Stateless proxies. If a proxy is stateless, then no 100 Trying will be sent
back to the UAC.
3. The UAS also sends 180 Ringing signifying that it has received the
INVITE. This response may be used to initiate local ring back.
4. The UAS sends a 200 OK message indicating that the request has
succeeded.
5. The UAC sends an ACK message confirming that the it has received a
final response to INVITE.
6. Media is exchanged.
7. When the call is disconnected, the UAC sends a BYE message.
8. The UAS sends a 200 OK final response.
Messages from the INVITE through the 200 OK are in both cases passed through
the Net-Net SD by virtue of the new top Via in the original INVITE added by the
Net-Net SD. But if the SD is acting as a stateful proxy, it will keep the Transaction
state in memory. The SD sends the 100 Trying back as it is able to absorb
retransmissions in case the UAC loses this 100 Trying message. A Stateless proxy
will not even spend resources sending this 100 Trying as it does not keep in
memory the state of the transaction.

2012 Acme Packet, Inc.

Copyright © 2010 asrbt.6.j.pm-9
Advanced Session Router And Business Trunking

Session Router working as Session Stateful

SIP-Config operation-mode is set to “session”. This means that the SR will
handle sessions, but not as a B2BUA, just as a Proxy. This mode differs from
the behavior of a B2BUA because it does not break dialogs. So, to handle all
messages from the same dialog, the SR needs to add at least 2 Via headers to
get all responses to the Transactions. Also it adds 2 Record-route headers to
get all transactions belonging to the same dialog back through it. Remember
that the Record-route header takes precedence over the Contact for indicating
where transactions need to be addressed inside the same dialog. The new
transactions will convert the content of those 2 Record-route headers into
Route headers and those will take precedence over the Request-URI for
routing.
In this mode we lose the media capabilities and all features related to it (LI, BW
CAC, QoS, etc)

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-10
Advanced Session Router And Business Trunking

Session Router working as Transaction Stateful

SIP-Config operation-mode is set to “transaction”. This means that the SR will
handle transactions only and will keep the state in memory, but not the entire
session state. This is again an operation mode of just a Stateful Proxy. This
mode differs from the behavior of a Session Stateful because it does not
maintain the session, so other transactions belonging to the same dialog will
not go through the SR. We still keep the 2 Via headers to indicate where to
send responses inside the same transaction, but no Record-route headers are
added. The SR operating in this mode will still send a 100 Trying back to the
caller to stop retransmissions as it is still able to absorb them in case they are
generated as it keeps in memory the original method.
This method is recommended to improve performance over the previous one,
but we can not use features that need to apply to the entire Dialog (Sip-NAT,
some HMRs, etc)
We also lose in this mode the media capabilities and all features related to it
(LI, BW CAC, QoS, etc)

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-11
Advanced Session Router And Business Trunking

Session Router working as Transaction Stateless

SIP-Config operation-mode is set to “stateless”. This means that the SR will
handle transactions only and will not keep the state in memory. This is again an
operation mode of just a Stateless Proxy. This mode differs from the behavior
of a Transaction Stateful because it does not maintain the transaction in
memory. We still keep the 2 Via headers to indicate where to send responses
inside the same transaction, but the routing back is done strictly following the
content of those Via headers present in the responses. The SR operating in this
mode will not even send a 100 Trying back to the caller to stop retransmissions
as it is not able to absorb them in case they are generated as it does not keep
in memory the original method.
This method is recommended to improve even more the performance over the
previous one, but we can not use features that need to apply to the entire
Dialog (Sip-NAT, some HMRs, etc)
In this mode we lose the media capabilities and all features related to it (LI, BW
CAC, QoS, etc)

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-12
Advanced Session Router And Business Trunking

Net-Net Session Router Advantages

High-performance SIP routing
Net-Net SR configurations are supported on three hardware platforms—the 1RU
Net-Net 4000 and 7 RU 9000 systems, and the Net-Net 4000 ATCA blade. Across
these platforms, transaction-stateful routing performance scales to 7200 SIP
message per second, stateless performance to 9800 messages per second. The
ability of these platforms to scale to these performance levels reduces the number
of session routing proxies required in a network, minimizing capital equipment and
operating expenses.
Extensive routing control, flexible routing database deployment
options
Leading routing database products and services from Acme Packet ecosystem
members are accessed via open, standards-based protocol interfaces—ENUM,
SIP, DNS, XML. These databases enable routing decisions for both the PSTN
SS7/C7 and IP networks and include LNP, CNAM, LERG, E911, LCR, private and
public ENUM and DNS. Routing decisions may be made using simple or very
sophisticated combinations of parameters. Standard routing parameters include any
combination of incoming network, destination number/URI, source number/URI,
time/day, cost, carrier preference and codec. Acme Packet’s powerful SIP header
and parameter manipulation rules enable routing by any number/URI in the SIP
header.
(Continued on next page)

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-13
Advanced Session Router And Business Trunking

Routing database information centralized/distributed to each Net-Net SR

The Net-Net SR best supports static, localized routing decisions using locally
provisioned policy rules and local route tables that can scale to 2 million routes.
Dynamic, global and even larger numbers of routing rules are best supported using
the high-capacity database products and services from Acme Packet’s OSR
ecosystem members. These choices provide tremendous deployment flexibility and
facilitate network evolution from small to large numbers of border points and from
PSTN to IP network-focused connectivity.

What’s Different between the Net-Net 7000 and the Net-Net 3000/4000
As stated on the previous slide, the overwhelming majority of features available on
other Net-Net Session Director platforms are available on the Net-Net 7000. There
are some differences, of course, which typically fit well with the applicable deployment
environments.
Net-Net 7000 operation is dependent on a USB stick installed on the hardware. This
stick is required for installation, operation and upgrades. In fact, product licensing is
dependent on it.
Licensing is based on a key value Acme Packet calculates based on the USB stick
installed in your server. When requesting a license, be sure to provide the serial number
indicated by the install procedure documentation. You apply the license, however, using
the same procedure you would use on other Acme Packet hardware.
Boot parameters differ as well, which are described in detail later in this presentation.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-14
Advanced Session Router And Business Trunking

Net-Net Platform and Solution Economics

Open, flexible and interoperable solution
From an IMS SIP signaling perspective, the Net-Net SR serves as the Breakout
Gateway Control Function (BGCF). This function is responsible for selecting the
optimum session border controller or softswitch/media gateway for sessions leaving
a provider’s network, and the Serving Call Session Control Function (S-CSCF) for
incoming sessions. For session security, the Net-Net SR offers hardware-
accelerated, high-performance, high-capacity IPsec and TLS encryption of SIP
signaling. Interworking of SIP transport and encryption protocols, and response
codes is also supported. The Net-Net SR configuration is available on Acme
Packet-designed systems as well as the Net-Net 4000 ATCA blade platform for
wireless and wireline ATCA chassis integration.
Carrier-class high availability
The Net-Net SR can continuously check external routing database availability and
utilize back-ups in the event of database server or network failure. Similarly, the
Net-Net SR can check egress SBC and softswitch/media gateway availability and
re-route if required. SIP transaction load balancing is also supported across multiple
SIP signaling elements. The Net-Net SR also protects itself against malicious or
non-malicious SIP DoS/DDoS attacks and overloads including mass calling events
such as contest or entertainment televoting. In the event of Net-Net SR failure, SIP
messaging transaction state is checkpointed between active and standby units to
ensure uninterrupted service.
Cost-effective, compact solution
In comparison with session-stateful, softswitch-based approaches, the compact
high-performance Net-Net SR platforms reduce capital and operational

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-15
Advanced Session Router And Business Trunking

expenditures as service providers transition to and evolve their next generation networks.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-15

Advanced Session Router And Business Trunking

Multi-Stage Routing
This feature has been introduced in Release 6.2 to increase the routing flexibility
allowing the result of a query to be used as input for a subsequent query. To enable
it, the single instance object session-router-config must be present and the
parameter additional-lp-lookups set to a number >0. By default this
parameter is set to 0.

If the policy-attribute next-hop specifies to use ENUM or LRT and an action of local-
policy-lookup lookup = multi, then the NAPTR result(s) change to the request-uri
should be used as the req-uri (to-address) key for the next LP lookup, in addition to
the other usual keys (from/source-realm). If multiple NAPTR results are returned,
each one should be tried (as previous behavior); this means each one causes
another local-policy lookup with a (possibly) new key.

If the policy-attribute next-hop specifies to use a hostname and an action of local-

policy-lookup lookup = multi, then that hostname should be used as the req-uri
hostname portion of the (to-address) key for the next LP lookup, in addition to the
other usual keys (from/source-realm). This should not actually change the name of
the req-uri in the message nor for subsequent lookups

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-16
Advanced Session Router And Business Trunking

Multi-Stage Routing

If the parameter multi-stage-src-realm-override is set to enabled under session-

router-config, and the policy-attribute realm field specifies a realm name and lookup
= multi, then that realm name should be used as the source-realm key for the next
LP lookup, in addition to the other usual keys (from/source-realm). Note that the
"real" source-realm should still be the one used for all other purposes, such as
CAC/steering-pool/etc. This should not actually change the source-realm for other
lookup attempts, however. This "pseudo" realm should not actually be required to
be a configured realm object, if possible, in order to avoid confusion in
configuration.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-17
Advanced Session Router And Business Trunking

Multi-Stage Routing Configuration

Limiting the number of stages per message lookup—The Net-Net SD can limit
to the number of additional local policy lookup stages it will perform by setting
received message to a maximum of 5. This is configured with the additional lp
lookups parameter. Leaving this parameter at its default value of 0 essentially
disables multistaged local policy lookups.
lookup—Leave this parameter at the default single for single stage local policy
routing or set it to multi to enable multistage local policy routing.
next-key—Set this parameter to $TO, $FROM, or $PAI if you wish to override
the recently-returned lookup key value for the next stage.
eloc-str-lkup—Set this parameter to enabled for the Net-Net SBC to parse the
emergency location string, as received in a CLF Line Identifyier AVP, for
emergency LRT lookup.
eloc-str-match—Set this parameter to the attribute name found in the location
string whose value will be used as a lookup key in the LRT named in the next-
hop parameter. Common values include “loc” or “noc”.

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-18
Advanced Session Router And Business Trunking

Topic Review: Session Router and OSR

What is the main limitation of class 4 networks routing?

Not centralized, updates needed when new routes added

What routing servers can be queried from a Session Router?

ENUM, LRT, CNAME, E911, DNS, LNP

What is the advantage of the OSR Architecture?

Simple Centralized routing, optimize call path

Provide the 4 operation modes for the Net-Net SD or SR?

Transaction Stateless, Transaction Stateful, Session Stateful or
dialog (B2BUA)

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-19
Advanced Session Router And Business Trunking

Copyright © 2012
2009 Acme Packet, Inc. asrbt.6.j.pm-20
Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-21

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-0
Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.i.pm-1

asrbt.6.j.pm-1
Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-2

Advanced Session Router And Business Trunking

Business Trunking
Business trunking connects PBXes to the PSTN via an IP network or to other
PBXes, with or without an Integrated Access Device (IAD). The IAD is used to
connect to legacy PBXes using PRI or BRI digital interfaces or FXO/FXS
analogue interfaces.
PBX to PBX configurations are more common within enterprise
implementations. Local calls inside the customer premises are routed by the
PBX itself. PBX networking protocols e.g. DPNSS, MCDN, Cornet, ABCNet,
QSig etc are not supported.
There are four basic methods to interconnect the service provider network as
shown. The role of the SBC is to “normalize” the traffic to conform to one or
more of these methods using IWF, HMR or the SIP-connect feature.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-3

Advanced Session Router And Business Trunking

Straight-through Trunking
In Straight-through trunking, the SBC is “transparent” to the traffic.
Commonly, we would have one IP address on the access side and one on the
core with a direct connection between them. Routing can take place, if
required, based on location code prefixes. You can also perform digit
manipulation if required.
This is a configuration-intense method, but it is very flexible in terms of meeting
the differing needs of individual PBXes or Trunks.
You can use this method for SIP only, H323 only, or IWF with any type of
routing, associated stack, static local-policies, Sip-NATs, and so forth.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-4

Advanced Session Router And Business Trunking

How Straight-through Trunking Works

There is a one to one relationship in the Net-Net SD between each PBX and
each core network interface. This implies that you need several peer and core
network-interfaces, realms, sip-interfaces or h323-stacks, steering pools, and
so forth.
Nevertheless, the Net-Net SD can perform IWF or do routing if required for
load-balancing purposes.
You can use any Net-Net SD routing mechanism with Straight-through
trunking. Local-policy is used most often, but associated-stack and Sip-NAT
configuration are also common.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-5

Advanced Session Router And Business Trunking

Sip Connect on the Net-Net SD

The Net-Net SD supports the SIP connect model, wherein PBXes register
themselves so that service providers do not need to know IP addresses or
locations in advance for static configurations. This is particularly helpful when
the PBX is behind a NAT.
During the PBX registration process, the PBX creates a binding between one of
its phone numbers as the address of record (AoR) and Contact-URI in the
REGISTER message. The registrar knows that the single AoR actually
represents many addresses, and so it registers them implicitly. However, the
registrar does not return the implicit AoR number in P-Associated-URIs.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-6

Advanced Session Router And Business Trunking

SIP Connect Applications

The SIP Connect feature resolves the following issues that arise from using this
model:
• SIP INVITEs sent to the PBX from the Registrar through the Net-Net
SD have the Request-URI of registered contact. Because it typically
ignores the To-URI, the PBX needs the Request-URI username
portion to be the specific extension number being called. With the
SIP connect feature enabled, the Net-Net SD overwrites the
Request-URI username with the To-URI username.
• SIP INVITEs from the PBX have the From AoR and Contact-URI
usernames of specific phones rather than the registered AoR and
Contact-URI. For the Net-Net SD, this means that it cannot use the
allow-anonymous parameter value of register; there would be no
registered user matches, and the Net-Net SD would reject them (with
a 403 Forbidden).
• With the SIP connect feature enabled, the Net-Net SD performs
allow-anonymous checking based on the registered Via address,
which is the same for all requests for the same PBX.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-7

Advanced Session Router And Business Trunking

SIP Connect Configuration on the Net-Net SD

For this configuration, registration caching must be enabled. For the realm from
which the registrations come, the options list must include sip-connect-pbx-reg.
The presence of this option instructs the Net-Net SD to skip matching the
Contact header in the INVITE request with the registered Contact of the
registration entry. Instead, the Net-Net SD finds a registration using only the
INVITE’s source address. Alternatively, you can configure the sip-connect-pbx-
reg option in the options list for an SA. When the realm from which an INVITE
originates does not have this option set, the Net-Net SD determines whether or
not the INVITE came from an SA. You might choose to configure SAs with this
option if you do not want it applied to an entire realm. If the PBX is behind a
NAT device, the SA’s IP address for the PBX (if statically configured) must be
the IP address of the NAT device. If DNS is used, the SA’s hostname must
resolve to the NAT device’s IP address.
Optional configuration
In the sip-ports configuration (located under the sip-interface branch of the
configuration tree) the allow-anonymous parameter must be set to registered.
This setting allows the Net-Net SD to accept SIP requests from SAs and
registered endpoints only, but to accept REGISTER requests from any
endpoint.
For the SIP interface that accepts registrations, the options parameter must be
set to reg-via-key. This setting allows the Net-Net SD to use the source address
of an INVITE as the key to find a registration entry in the registration cache.
When the INVITE’s Contact header matches the registered Contact in the
registration entry, the Net-Net SD accepts the INVITE request.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-8

Advanced Session Router And Business Trunking

Trunk Group Routing Principles

The SIP protocol includes a header that can be used for routing messages via
“trunks”. The information is included in the Request-URI and can be set to
“IPTEL”, “trunk-group” or “trunk-context”. The Net-Net SD can recognize these
settings and route accordingly. No other routing configuration is required.
The simplest Net-Net SD configuration uses a realm, associated with the trunk-
context and an SA associated with the trunk group.
The use of trunking requires that other devices in the core, including the soft
switch support TG-URIs (Trunk Group) however when implemented, it can
vastly simplify provisioning.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-9

Advanced Session Router And Business Trunking

Trunk Group Routing Examples

There are many applications that you can set up on the Net-Net SD to take
advantage of SIP’s trunk-group and trunk-context headers.
Let’s consider a PBX that is originating methods using trunk-group and/or trunk-
context headers. A common application in this context is to configure the PBX
as a SA on the Net-Net SD. Next, you configure that SA to support trunk-group
and/or trunk-context. Finally, you configure the Net-Net SD to use header
manipulation to pull the data from trunk-group and/or trunk-context and insert it
into the re-originated methods’ contact headers.
In this case, you are providing the service provider with information about which
PBX is originating calls that they can then use for billing and SLA purposes.
Consider traffic flowing in the opposite direction, to the PBX. For traffic that has
an application server set to trunk-group and/or trunk-context, the Net-Net SD
can use that information to select a destination, which is typically an SA.
This configuration allows you to support routing with an extremely efficient
configuration that avoids the use of a local policy for a multitude of PBXes with
different and non-contiguous numbering plans.
Even if the PBX does not support those parameters in the Request-URI, you
can configure the Net-Net SD with an egress HMR to remove them so the
destination accepts the sessions.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-10

Advanced Session Router And Business Trunking

Specific Configuration for Trunk Group Routing

The Net-Net SD parameter that triggers trunk group routing is the term-tgrp-
mode in the ingress Sip-Interface. You set the mode depending on the format
received, either iptel or egress-URI. You can also use SAs for both reading
internal variables and adding them in the contact. For this purpose, set the SA
trunk-group parameter to tgrp:trunk-context.
Note that you can also set the trunk-group parameter in a SAG to apply load
balancing.
You do not need the trunk-context set on the SA. This could instead be set at
the realm level. Of course no trunk context is needed if the trunk group itself
already indicates a valid next-hop, such as an IP address.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-11

Advanced Session Router And Business Trunking

Trunk Group Routing Configuration Elements

There are two main configuration elements needed to route using trunk groups,
the sip-interface and the session-agent.
Note that SAGs allow you to load balance between trunk groups. In addition,
you can use an HMR to add or remove parameters in the Request-URI or
contact for egress or ingress sessions.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-12

Advanced Session Router And Business Trunking

Configuring the Realm with Trunk Context

In some cases, the tgrp parameter comes with a next hop defined in the form of
an IP address or FQDN. Even if this is the case, a source still must be defined.
You can use the Net-Net SD to resolve this issue by setting the trunk-context in
the ingress realm. When the Net-Net SD sees this parameter, it selects this
realm as the egress. This means that the sip-interface associated with the
realm originates the session. This mechanism is very efficient and simple to
configure.
In addition, calls entering a realm with the trunk-context parameter set have the
internal variable populated. This allows us to include it in the contact of the
egress session.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-13

Advanced Session Router And Business Trunking

Example for adding tgrp trunk-group in the Contact

Example: The Goal is to add Orig Tgrp Params in IPTEL format:

sip-manipulation
name add_iptel
header-rule
name contact
action manipulate
match-value
msg-type any
element-rule
name tgrp
type uri-user-param
action add
match-val-type any
match-value
new-value $TRUNK_GROUP
element-rule
name trunk-context
type uri-user-param
action add
match-val-type any
match-value
new-value $TRUNK_GROUP_CONTEXT

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-14

Advanced Session Router And Business Trunking

Surrogate Registration
The Net-Net SD surrogate registration feature lets the Net-Net SD register on
behalf of a Internet Protocol Private Branch Exchange (IP-PBX). After you
configure a surrogate agent, the Net-Net SD periodically generates a
REGISTER request and authenticates itself using a locally configured
username and password with the Net-Net SD as the contact address.
Surrogate registration also manages the routing of class from the IP-PBX to the
core and from the core to the IP-PBX.
With surrogate registration, the Net-Net SD lets IP-PBXes integrate with the IP
Multimedia Subsystem (IMS) architecture. The IP-PBX registers itself as if it
were user equipment (UE), which triggers the implicit registration of all phone
numbers associated with the IP-PBX.
Implicit registration means the registration of one address of record (AoR)
triggers the automated registration of all the other AoRs associated with that
UE. The automated registered AoRs are passed back to the UE (in this case
the Net-Net SD) as P-Associated-URIs in the registration’s 200 (OK).
IMS assumes that each SIP endpoint can register itself with its Serving-CSCF
(SCSCF). However phones can be connected to SIP Integrated Access
Devices (IADs) or SIP or H.323 IP-PBXes. The Net-Net SD performs SIP
registration on behalf of the IP-PBX and IADs. It can handle routing in both
directions respecting both sides rules.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-15

Advanced Session Router And Business Trunking

How Surrogate Registration works

The Net-Net SD registers on behalf of the IP-PBXes and then stores the
associated URIs returned by the Call Session Control Function (CSCF). The
calls from the phones behind the IP-PBX can be routed based on the cache
entry the Net-Net SD creates after it receives each phone’s associated URI.
Calls are routed using the service route, local policy or any other routing
mechanism based on the associated SA or SAG. The Net-Net SD also
supports multiple registrations on behalf of an IP-PBX because the IP-PBX can
support thousands of phones, but the registrar might only be able to send 10 to
20 associated URIs in response to a single registration.
The Net-Net SD replaces the Contact URI for requests from the IP-PBX to the
core to match the registered value. For calls from the IMS core to the IP-PBX,
the Net-Net SD replaces the Request-URI username with P-Called-Party-
ID/To-URI username. The IMS core sends INVITES for the phones behind the
IP-PBX with the registered Contact URI as the Request-URI instead of the AoR
of the phones. The IP-PBX needs to see the phone’s AoR in the Request-URI.
The calls coming from the core will have the Net-Net SD’s Contact-URI (which
is sent in the REGISTER request) as the Request-URI. The Net-Net SD looks
for a registration entry that corresponds to this URI. After finding the registration
entry and the corresponding surrogate agent, the Net-Net SD looks for the
routing mechanism it should use to route this INVITE to the IP-PBX. It uses the
customer-next-hop configuration parameter to determine if it routes this call to
the SA, the SAG, or directly to a particular IP address.

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-16

Advanced Session Router And Business Trunking

Surrogate-agent Configuration Parameters

Move to configuration mode, session-router, surrogate-agent and configure the
following parameters:
register-host — Enter the registrar’s hostname to be used in the Request-URI of the
REGISTER request. This name is also used as the host portion of the AoR To and
From headers.
register-user — Enter the user portion of the AoR. If we have several because Aor-
count is > than 1, then we need to insert 700^ (^ being the variable number)
state — Set to enabled (default) or disabled to indicate whether the surrogate agent is
used by the application.
realm-id — Enter the name of realm where the surrogate agent resides (where the IP-
PBX proxy resides).
description — Optional. Enter a description of this surrogate agent.
customer-host — Optional. Enter the domain or IP address of the IP-PBX, used to
determine whether it is different from the one used by the registrar.
customer-next-hop — Enter the next hop to this surrogate agent: SAG (SAG: <SAG
name>) or SA (<hostname> or <IPV4>) or specific IP address (<IPV4> or <IPV4: port>)
register-contact-host — Enter the hostname to be used in the Contact-URI sent in the
REGISTER request. This should always point to the Net-Net SD. If specifying an IP
address, use the egress interface’s address.
register-contact-user — Enter the user part of the Contact-URI that the Net-Net SD
generates. If we have several because Aor-count is > than 1, then we need to insert
700^ (^ being the variable number)
“Continued on next page.”

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-17

Advanced Session Router And Business Trunking

Surrogate-agent Configuration Parameters (cont.)

Password—If you are configuring the auth-user parameter, you need to enter
the password used in case the registrar sends the 401 or 407 response to the
REGISTER request.
Register-expires—Enter the expires in seconds to be used in the REGISTER
requests. Default value is 600,000 (1 week).
replace-contact—Set to enabled or disabled (default). This specifies whether
the Net-Net SD needs to replace the Contact in the requests coming from the
surrogate agent. If this is enabled, Contact will be replaced with the Contact-
URI the Net-Net SD sent in the REGISTER request.
Route-to-registrar—Set to enabled (default) or disabled. This indicates
whether requests coming from the surrogate agent should be routed to the
registrar if they are not explicitly addressed to the Net-Net SD.
Aor-count—Enter the number of registrations to do on behalf of this IP-PBX. If
you enter a value greater than 1 (default), the Net-Net SD increments the
register-user and the register-contact-user values by that number. For example,
if this count is 3 and register-user is john, then users for three different register
messages will be john, john1, john2. It does the same for the register-contact-
user values.
Options—Optional. Enter non-standard options or features.
Auth-user—Enter the authentication user name you want to use for the
surrogate agent. This name is used when the Net-Net SD receives a 401or 407

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-18

Advanced Session Router And Business Trunking

Pros and Cons of all options

Straight-through: This is the easiest and the traditional way to configure
trunking. All the BCP models will fit in this category. It is also flexible in terms of
features but it requires a detailed configuration effort, so it is not recommended
for most of the big deployments
Trunk Group URI: This option is excellent for large configurations, as it
requires minimum configuration load and allows a lot of flexibility. However it
requires an IMS network supporting the parameters tgrp (trunk group) and
trunk-context in the Request-URI. Additional HMR configuration may be
necessary to cover all requirements with a very high degree of flexibility
SIP Connect: This option is very easy to implement, convenient for large
configurations as well, but it requires all PBXes to support it
Surrogate Registrations: This is a very good solution for increasing service
reach of non-IMS compliant users or H.323 devices to be able to register in a
SIP environment. However it also requires the Core to support this type of
operation (Send a correct URI and a P-Called-Party-ID header). It also requires
the core to handle additional registrations from the Net-Net SD. All registrations
from same surrogate-agent if they are challenged, they need to have the same
password, as the configuration only allows one password field for all the range
of users

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-19

Advanced Session Router And Business Trunking

Topic Review: Business Trunking

What is the main objective of the Business trunking solution?

Connecting PBXes to the PSTN via an IP network

What are the four applications available in this solution?

Straight-through trunking, Sip Connect, Trunk group URI, Surrogate
Registrations

What is the advantage of Trunk group URI versus using Local policies for
routing?
Simple light and flexible configuration on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-20

Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-21

Advanced Session Router And Business Trunking

Copyright © 2012 Acme Packet, Inc. asrbt.6.j.pm-22

ahmr.6.j.pm-0
 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-1

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-2

 Advanced HMR on the Net-Net SD

HMR Overview
Header Manipulation Rules (HMR) provide the Net-Net Session Director (SD)
with the ability to insert, delete, or modify any SIP header or parameter. You
can also use HMR to copy or move header or parameter values, rename
parameter names, and delete MIME attachments. Any of these functions can
be performed based on the type of message (request vs. response), the type of
request (Invite, Register, etc.), or based on the success or failure of regular
expression matching of any other header or parameter in the same message.
The HMR function can be used in many ways - from modifying messages for
interoperability reasons, to routing requests differently based upon matched
values, to anonymization and identity assertion. HMR rules are a set of tools,
whose usefulness depends a great deal on the user's imagination and
understanding of the SIP protocol and the Net-Net SD's capabilities.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-3

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-4

 Advanced HMR on the Net-Net SD

HMR example
This HMR example shows a header-rule along with its element rule.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-5

 Advanced HMR on the Net-Net SD

HMR on the Net-Net SBC

Using HMR you can search a header for dynamic content or patterns with the
header value. Search for all User parts of a URI that begin with 617 and end
with 5555 (e.g., 617...5555). Modify 617 123 5555 to become 617 231 5555 or
508 1230000, or any combination of numbers you specify.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-6

 Advanced HMR on the Net-Net SD

SIP Manipulations
Each sip-manipulation object defines a set of header rules (HRs) and element
rules (ERs) for use as an inbound or outbound HMR rule-set. Only one sip-
manipulation ruleset can be applied to a session-agent, realm, or sip-interface
inbound and outbound.
When you set the parameter to sip-manip, you then configure the new-value
parameter with the name of a SIP manipulation rule that you want to invoke.
The values for the match-value, comparison-type, and methods parameters for
an invoked rule are all supported. This means that the manipulation defined by
the rules identified in the new-value parameter are carried out when the values
for the match-value, comparison-type, and methods parameters are true.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-7

 Advanced HMR on the Net-Net SD

HMR on the Net-Net SD

Before understanding the Net-Net SD HMR model, you need to know when
HMR operates during overall packet processing as well as what HMR can and
cannot do. HMR rules are performed on one of two "sides" of the Net-Net SD's
processing: inbound and outbound. Where they are performed depends on an
inbound-manipulation-rule or an outbound-manipulation-rule. Even within that
construct, you can apply HMRs inbound or outbound on a session-agent, SIP-
interface, or a realm. The order of preference is session-agent > realm > sip-
interface. It is important to remember that a sip-manipulation rule (HMR)
applied to a session-agent will override the realm or SIP-Interface HMR. The
realm HMR will override a SIP-interface HMR.
As an outbound rule, the HMR rules are applied just before the SIP message is
sent out by the Net-Net SD; after SIP-NAT processing. Any changes made by
an outbound HMR rule will affect the message, and will not be overridden by
the Net-Net SD in any way.
Rulesets are performed in a stateless manner, meaning they do not know
anything about previous messages or about messages which were received by
the Net-Net SD for the same transaction or dialog.
Inbound rulesets are applied before SIP-NAT and most processing of the Net-
Net SD, but after some SIP parser processing is performed. This is because
the message's source must be determined to decide to which session-
agent/SIP-interface/realm it belongs. It is also performed after basic SIP
message parsing is performed in order to verify the message is well-formed
and follows the specifications. This is necessary to securely perform any
subsequent message processing, including HMR. Because of this, one cannot
typically use inbound HMR to fix mal-formed messages, if they are so mal-
formed that the parser rejects them.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-8

 Advanced HMR on the Net-Net SD

What happens before routing decisions are made?

It is important to understand the order in which the Net-Net SD performs all the
different functions to understand what impact HMRs can a have on routing
decisions. We need to be aware that before routing, there is a revision of the
structure and validity of the ingress SIP messages (called parsing). It is after
this that the Net-Net SD applies the inbound header manipulation. Taking this
into account, we can use those inbound HMRs to modify the routing behavior,
something that can be very beneficial by increasing the flexibility of the routing
options.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-9

 Advanced HMR on the Net-Net SD

Topic Review: Basics of HMR

Using HMR you can:
Insert, delete, or modify any SIP header or parameter
Copy or move header or parameter values
Rename parameter names

And what else?

Manipulate SDP or any other Body Type

How many rule-sets can be applied to an inbound message?

Only one rule-set is applied to an inbound message

What is basic SIP message parsing?

Parsing is a verification that the SIP message is well-formed and follows the
RFC 3261 specifications.

Which elements can you apply an HMR to?

Session Agent, Realm and SIP Interface

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-10

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-11

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-12

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-13

 Advanced HMR on the Net-Net SD

The sip-manipulation element

Syntax header-rules <name | action | match-value | msg-type | methods
|element-rules | header-name | comparison-type | new-value | batch| select | no
| show | done | exit>
Header-rule Parameters
name — Enter the name of the header to which this rule applies. This name
must match a header name. Header manipulation rules operate on the header
you specify when you configure the rule. A header manipulation rule can also
be configured with a list of element rules, each of which would specify the
actions you want performed for a given element of this header. Header element
rules perform operations on the elements of a header. Header elements include
all subparts of a header, excluding the header name; i.e. header value, header
parameter, URI parameter, and so on.
To manipulate the SDP body: Set the header-name to Content-type. Set the
parameter-name to application/SDP.
TechNote: In previous releases (4.0x), the HR names actually defined the
name of the SIP header the HR applied to, for example "Contact" or "From".

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-14

 Advanced HMR on the Net-Net SD

Header-rules Actions
action — Enter the action you want applied to the header specified in the name
parameter. The default value is none. Valid options are:
add — Add a new header, if that header does not already exist
delete — Delete the header, if it exists
manipulate — Elements of this header will be manipulated according
to the element rules configured
store — Store the header
sip-manip — points the ruleset to a previuosly configured ruleset
find-replace-all — matches and replace a specified value
none — No action to be taken
find-replace-replace – Replace all of an element

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-15

 Advanced HMR on the Net-Net SD

Reject and Log actions

log - A new action of "log" is now supported in all rule types. If the rule it's in
successfully matches the conditions within the rule (match-value, msg-type, etc.), it
will log pieces of the SIP message into a new log file called "matched.log" (which is
a rolling incrementing log like all the others). Note that on a 9200, this is in the SIP-
T cores, and obviously only the SIP-T core which executed the rule will have it in its
matched.log file.
The format of the matched.log is similar to sipmsg.log and contains a timestamp,
received/sent Net-Net SD network-interface, local IP Address and port it was
received on or being sent from, and which remote IP Address and port it was
received from or sent to. Additionally the log file will contain which rule triggered the
log action in the syntax of rule-type[rule-name]. It will also contain the request-URI,
From, To and Contact headers

reject - A new action of "reject" is now supported in all rule types. If the rule
successfully matches the conditions within the rule (match-value, msg-type, etc.), it
will increment a counter, and if it's a SIP Request it will reject it; a response will not
be rejected (but the counter will still be incremented). The counter is visible as a
new "Rejected Messages" entry in the table shown by "show sipd status", and is
available in a new MIB object in the ap-smgmt.mib for SNMP get. An SNMP Trap
has also been created, which will be sent if the number of Rejected messages
exceeds a configured threshold in a configured time window (which are set by the
new reject-message-threshold and reject-message-window config attributes in
session-router).

You can also specify what response-code and reason-phrase to use in rejecting the
SIP Request in the Rule you have the "reject" action in, by entering the "status-
code[:reason-phrase]" in the new-value field. For example "403:You are naughty" in
new-value of a reject action rule will make the SD reject the request with a 403
response and "You are naughty" as the reason-phrase.
Note: if the message is a Request and thus gets rejected by a Rule, later Rules
don't get executed - the message is rejected immediately.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-16

 Advanced HMR on the Net-Net SD

Header-rule match-value
Specifies the value to match against the header value in SIP packets. The Net-
Net SD matches these against the entire SIP header value. This is where you
can enter values to match using regular expression (regex) values. Entries can
also contain boolean operators.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-17

 Advanced HMR on the Net-Net SD

Header-rule msg-type
Default value is “any”, Requests and Reply messages. Other values are:
• request — Request messages only
• reply — Reply messages only
• out-of-dialog — For out-of-dialog messages only
The new setting out-of-dialog addresses the challenge of disrupting the
dialog, by offering a way of dialog matching of messages for inbound and
outbound HMR requests. It becomes matching criteria for operations
performed against a message. You can also combine with method criteria
therefore only affecting those methods.
For both inbound and outbound manipulations, using the out-of-dialog setting
means the message must be a request without a to-tag in order to perform
the manipulation.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-18

 Advanced HMR on the Net-Net SD

Out-of-dialog for in-manipulations

Since inbound manipulations take place before the message reaches the core
of Net-Net SD SIP processing, the SIP proxy takes the manipulated header as
what was directly received from the client. This can cause problems for
requests leaving the Net-Net SD for the UAC because the dialog will not match
the initial request sent. So the unmodified header must be cached because for
any subsequent request (as in the case of a BYE originating from the
terminator) the Net-Net SD might need to restore the original value—enabling
the UAC to identify the message correctly as being part of the same dialog. For
out-of-dialog requests (when the To, From, or Call-ID headers are modified) the
original header will be stored in the dialog when the msg-type out-of-dialog is
used.
The Net-Net SD performs the restoration of original headers outside of SIP
manipulations. That is, there are no manipulation rules to configure for restore
the header to their original context. The Net-Net SD will recognize the headers
have been modified, and restore them to their original state prior to sending the
message out on the wire. Restoration takes place prior to outbound
manipulations so that any outbound manipulation can modify those headers
once they have been restored.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-19

 Advanced HMR on the Net-Net SD

Out-of-dialog for out-manipulations

When you use the out-of-dialog setting for an outbound manipulation, the Net-
Net SD executes this specific SIP header rule only if the same SIP header rule
was executed against the initial dialog-creating request.
For example, if the INVITE’s To header was not manipulated, it would not be
correct to manipulate the To header in the BYE request. To do so would render
the UAC unable to properly match the dialog. This also means that the
outbound manipulation should be carried out against a To, From, or Call-ID
header in the BYE request if it was manipulated in the INVITE.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-20

 Advanced HMR on the Net-Net SD

Header-rule comparison-type
Comparison-type specifies the way that you want SIP headers to be compared.
This choice dictates how the Net-Net SD processes the match rules against the
SIP header. The default is case-sensitive. The valid values are Boolean | case-
sensitive | case-insensitive | pattern-rule.
The two new values refer-case-sensitive | refer-case-insensitive will make
reference to the content of the variable instead of taking the name of that
variable in the match-value. i.e. the match-value is
$TRUNK_GROUP_CONTEXT and we want to compare with the value of the
parameter trunk-context in the user part of the URI instead of comparing with
the string “$TRUNK_GROUP_CONTEXT”
Using refer-case-sensitive or refer-case-insensitive is incompatible with action
set to store, because if we set the action to store, the match value is
understood as a Regex pattern and therefore it does not work.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-21

 Advanced HMR on the Net-Net SD

Header-rule new-value
Specifies the value of the header to include in SIP packets; the Net-Net SD can
use Strings, Variables or a combination of both, as we will see in next slide.
The header-name parameter will be the header to be created. If you want to
modify only part of a message header, use the new-value in the element-rule
and not in the header-rule as we can specify the part where to introduce the
new-value much better.
‘+’ is used to append/concatenate, ‘^+’ is for prepend
‘-’ is used to truncate/cut, and ‘^-’ is used to truncate from the front

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-22

Advanced HMR on the Net-Net SD

Configuring Element-Rules
The new-value parameter indicates the new value to be added/pre-
pended/appended to the value matched. Parameter insertion options include:
• $LOCAL_IP -- predefined parameter specifying to use the LOCAL IP;
• $ORIGINAL -- original value of element;
• $LOCAL_FQDN -- predefined parameter specifying to use the
LOCAL FQDN;
• $REMOTE_IP -- predefined parameter specifying to use the
REMOTE IP;
• $REMOTE_FQDN -- pre defined parameter specifying to use the
REMOTE FQDN;
• “string” -- use the absolute value in the quotes;
• “string”+ -- specifies absolute value in quotes be pre pended to the
original value of the element; and
• +”string” -- specifies absolute value in quotes be appended to the
original value of the element.
• $<Header-name>$<Element-rule>.$x (X=0 to 9) – This pastes the
result of a previous store action.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-23

Advanced HMR on the Net-Net SD

New Variables
Using these new reserved variables works like user-defined variables, NOT like
previous reserved variables, such that you MUST use the "$variable.$0" syntax.
For example "$PAI_USER.$0". If you don't use that $0, you'll get the
TRUE/FALSE (which is useful if for example there were no username in the
PAI header, or no PAI header at all). The legacy reserved words from previous
releases continue to work as they did, but you can ALSO use the ".$0" syntax
with them - but not using it still works for getting the string, and is ok usually
since most of the user-defined variables can't be TRUE/FALSE. The only ones
that could have been TRUE/FALSE were TRUNK_GROUP,
TRUNK_CONTEXT, and MANIP_STRING - so to make things consistent now
we've added some new ones which work the new way: "$T_GROUP",
"$T_CONTEXT", and "M_STRING" now work the new way for the same
concept as TRUNK_GROUP, TRUNK_CONTEXT, and MANIP_STRING

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-24

Advanced HMR on the Net-Net SD

HMR specific to Customer

$MANIP_STRING is a system variable that can be used in the new-value of a sip-
manipulation pulling the value from the sip-interface/realm/session-agent. This will be
configured in the parameter manipulation-string of any of those elements
$MANIP_PATTERN can be used in a match-value of a pattern-rule comp-type, to use a
regex pattern from the most-specific matching session-agent/realm/sip-interface. In
those 3 elements, a new config attribute called "manipulation-pattern" lets you enter a
regular expression, and thus have unique regex patterns per session-agent/realm/sip-
interface without needing to create unique HMRs (sip-manipulations) for each of them.
Only one regex pattern can be specified in the config attribute, and only the variable
$MANIP_PATTERN can appear in the match-value field (i.e., you cannot combine the
"$MANIP_PATTERN" with additional characters in the match-value).
You can use this $MANIP_PATTERN in any rule in which you can use a pattern-rule
match-value, including store action rules. You can also reference the stored values from
that in later rules in the usual way (i.e., using the $RuleName for the boolean
TRUE/FALSE, or $RuleName.$0 for the whole matching string, etc.).
Since the $MANIP_PATTERN is dynamically decided at run-time every time the sip-
manip executes for each message, it's possible that no configured manipulation-pattern
will be found (i.e., the config was wrong), and if that happens, it will use the default
(which is "\,+", which works like ".+" for most things). Also, since it's decided at run-time,
it's possible you could have referenced a sub-group that was not in the pattern chosen
(i.e., you did $RuleName.$2 but the pattern found in sip-interface only had one or no
parenthesis group) - in that case it will resolve to empty/FALSE.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-25

 Advanced HMR on the Net-Net SD

Header-rule methods
Enter a list of SIP methods to which this header rule applies. An empty value
applies this header rule to all SIP method messages - excluding keywords add
and delete. When a list is already configured, it replaces the entire list.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-26

 Advanced HMR on the Net-Net SD

Element-rules
Sip-element-rules are sub-elements of the header-rule. They define specific
components and parts of the header on which we want to perform an action. It
is highly recommended ERs be used as much as possible - especially with
regex HMR.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-27

 Advanced HMR on the Net-Net SD

HMR element-rule name field

The ER name field along with the parameter-name field are now distinct in that
one can perform multiple actions or rules for the same parameter-name
multiple times. For example, one could store a parameter value and delete the
same parameter later. Also, the ER name can be used in subsequent HRs and
ERs - if the ER was stored.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-28

 Advanced HMR on the Net-Net SD

HMR element-rule parameter-name

The ER parameter-name along with the ER name field are now distinct so that
one can perform multiple actions/rules for the same parameter-name multiple
times.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-29

 Advanced HMR on the Net-Net SD

HMR element-rule type

You can find this information in the ACLI Reference Guide for Net-Net OS-C6.0
and above.
In Release Cx6.2 there have been two additions;
1. uri-user-only is URI username without the URI user parameters, if there are
any. Examples are the tgrp or trunk-context or the rn (Route Number) or cic
(Customer Id Code).
2. uri-phone-number-only takes only the numbers that appear in the user part
of the URI, not parameters or symbols like -, + or ( ).

TechNote: URI - Uniform Resource Identifier

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-30

 Advanced HMR on the Net-Net SD

Element Rule type header-value

This is the full value of the header, defined as the header field-value in section
7.3.1 of RFC 3261.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-31

 Advanced HMR on the Net-Net SD

Element Rule type header-param

This is the full value of the header parameter, defined as the parameter-
name=parameter-value in section 7.3.1 of RFC 3261.

TechNote: maddr: The maddr parameter indicates the server address to be

contacted for this user, overriding any address derived from the host field.
When an maddr parameter is present, the port and transport components of the
URI apply to the address indicated in the maddr parameter value. The maddr
field has been used as a simple form of loose source routing. It allows a URI to
specify a proxy that must be traversed en route to the destination. Continuing to
use the maddr parameter this way is strongly discouraged

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-32

 Advanced HMR on the Net-Net SD

Element Rule type header-param-name

Used to change the parameter name itself.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-33

 Advanced HMR on the Net-Net SD

Element Rule type uri-user

As defined by the ABNF for "user" in section 25.1 of RFC 3261.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-34

 Advanced HMR on the Net-Net SD

Element Rule type uri-host

As defined by the ABNF for “host" in section 25.1 of RFC 3261.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-35

 Advanced HMR on the Net-Net SD

Element Rule type uri-display

As defined by the ABNF for “uri-display" in section 25.1 of RFC 3261.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-36

 Advanced HMR on the Net-Net SD

Element Rule type uri-param

As defined by the ABNF for “uri-parameter" in section 25.1 of RFC 3261.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-37

 Advanced HMR on the Net-Net SD

Element Rule type status-code

The example above shows a manipulation on a SIP response. When the
header-name of the HR is status-line, the response will be changed from a
status code of 404 to a 200.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-38

 Advanced HMR on the Net-Net SD

Element Rule type reason-phrase

The example above shows a manipulation on a SIP response. When the
header-name of the HR is status-line, the reason-phrase will be changed from
No routes found to Ping OK.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-39

 Advanced HMR on the Net-Net SD

Element-rules action
The action element determines what the ER will do.
An action of "none" means the ER will not be performed, which is useful to
temporarily disable an ER, or to reserve a spot for an ER in the chain of ERs for
an HR.
An action of "store" means the ER will store values which are matched by the
match-value configuration element. The values stored are available for use in
later HRs or ERs of later HRs, which will be described later.
An action of "replace" means the ER will replace the value of the element to
which it is applied. For example, if the addTgidParam action were "replace"
instead of "add", it would replace an existing tgid parameter value with the new-
value. The name of the parameter would not change in this case, unless the ER
type were "uri-param-name", in which case the name of the parameter would
be replaced by the new-value, instead of the replacing the value of the
parameter.
An action of "add" adds the ER type, unless a parameter of the same name
already exists. The name of the new parameter will be the ER parameter-
name, and the value of the new parameter will be the new-value configuration
element.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-40

 Advanced HMR on the Net-Net SD

HMR example - remove

This basic HMR removes the Subject header from a SIP Request message.
The rule checks whether the header specified in the header-name field exists,
and if found, performs a delete action.

TechNote: This HMR example doesn’t require element-rules.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-41

 Advanced HMR on the Net-Net SD

HMR example replace user uri-param

This HMR first deletes the user uri-param and then adds a uri-param,acme,
with a new value in the Contact header of SIP messages

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-42

 Advanced HMR on the Net-Net SD

HMR example replace user uri-param

This more complex HMR performs some replace actions on a SIP
answer/response to an OPTION method. This rule contains an HR header-
name of @status-line, which indicates we are manipulating an answer. This
HMR will replace a 404 No routes found reply message with a 200 Ping OK
response.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-43

 Advanced HMR on the Net-Net SD

Complete HMR example

This ruleset adds the tgrp and trunk-context parameters with their values to the
Contact header of an egress INVITE. The parameters values are extrapolated
by the pre-defined values $TRUNK_GROUP and
$TRUNK_GROUP_CONTEXT. This will allow the Core to perform billing by
looking at those two parameters.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-44

 Advanced HMR on the Net-Net SD

Applying Rulesets to SIP-Interface

The configured ruleset is applied to the SIP interface in the out-manipulationid
parameter. SIP manipulations may be applied incoming (before realm bridging
has occurred) or outgoing (after realm bridging has occurred).
When you apply SIP manipulation rulesets to a SIP interface incoming, you
may affect the way SIP messages are translated and routed.
When you apply SIP manipulation rulesets to SIP interface outgoing, the
manipulation is done after realm bridging has occurred. Generally, this means
that the manipulation is not intended to affect next hop decisions. Rather it is
being used to alter SIP header elements in order to hide topology. SIP
manipulations may be used for more advanced functions, such as inserting
administrator-defined cookies, stripping proprietary fields, etc.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-45

 Advanced HMR on the Net-Net SD

Prebuilt SIP Manipulations

Release Cx6.2 introduced prebuilt HMRs. The first one is the typical one that
most customers using the PBRB+HMR Model in Peering were using to hide the
IP appearing in the host part of the To and From headers. In future releases
there will be more, mainly the ones that are vastly deployed between Acme
Packet customers.
The command to check preconfigured HMRs is show built-in-sip-manipulation

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-46

 Advanced HMR on the Net-Net SD

Topic Review: The sip-manipulation element

Are element-rules required in a simple ruleset that removes a SIP header?
No.

How many rulesets can be applied to a realm?

1 inbound and 1 outbound ruleset per realm.

What sip-interface parameter would you use to apply an HMR to an outbound

SIP messages?
out-manipulationid.

What is the element preference order in which the Net-Net SD handles HMRs?
Session Agent >Realm>Sip Interface.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-47

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-48

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-49

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-50

 Advanced HMR on the Net-Net SD

Regular Expressions
In computing, regular expressions provide a concise and flexible means for
identifying strings of text of interest, such as particular characters, words, or
patterns of characters. Regular expressions (abbreviated as regex or regexp,
with plural forms regexes, regexps, or regexen) are written in a formal language
that can be interpreted by a regular expression processor, a program that either
serves as a parser generator or examines text and identifies parts that match
the provided specification. Regular expressions are used by many text editors,
utilities, and programming languages to search and manipulate text based on
patterns.

TechNote: POSIX Basic Regular Expressions

Traditional Unix regular expression syntax followed common conventions but
often differed from tool to tool. The IEEE POSIX Basic Regular Expressions
(BRE) standard (released alongside an alternative flavor called Extended
Regular Expressions or ERE) was designed mostly for backward compatibility
with the traditional (Simple Regular Expression) syntax but provided a common
standard which has since been adopted as the default syntax.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-51

 Advanced HMR on the Net-Net SD

Regex Characters
In the POSIX regex syntax, the one the Net-Net SD utilizes, as in most regex
syntaxes, most alphanumeric characters one can type on a keyboard are called
"literal" or "ordinary" characters, meaning they represent their actual literal
value in the pattern. For example, the regex pattern sip is a pattern of all literal
characters that will be matched from left to right, at each position in the input
string, until a match is found. Given an input string of <sip:[email protected]>, the
regex pattern sip will successfully match the sip, starting at the position of the 's'
and ending at the position of the 'p'. However, the same regex will also match
sip in <sips:[email protected]>, and tel:12345;isip=192.168.0.3, because an s
followed by an i followed by a p exists in both of those as well.
Some characters in regex have special meaning, and are not treated as literal
characters; these characters are called "special characters" or "meta-
characters". These meta-characters have special meaning, which will be
discussed later. Meta-characters include the '.' (called the dot), '*' (star or
asterisk), '+' (plus), '|' (bar), '?' (question mark), '[' (left or opening bracket), '\'
(backslash), ‘( ' (left or opening parenthesis), '{' (left or opening brace), '^'
(circumflex or caret), and '$' (dollar sign). In order for any of these characters
to be treated literally, they must be escaped with a '\' before them, including the
'\' meta-character itself.
There is one exception to the above characters being special: inside a []
bracket pair, called a character class, the '.' dot, '*' star, '+' plus, '|' bar, '?'
question mark, '[' left bracket, '(' left parenthesis, '{' left brace, and '$' dollar sign
are not special and are handled as their literal character values. The '^' caret is
not special in a character class except when it is the first character following the
'['. There are more rules about special characters inside a bracketed character
class which will be discussed later.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-52

 Advanced HMR on the Net-Net SD

13 Regex special meaning characters

The square brackets []
The backslash \
The caret ^
The dollar sign $
The period or dot .
The vertical bar or pipe symbol |
The question mark ?
The asterisk or star *
The plus sign +
The opening round bracket (
The closing round bracket )
The squiggly brackets {}
The word boundary \b

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-53

 Advanced HMR on the Net-Net SD

The Period Character

The '.' dot, when treated as a special character (which is anytime it's not inside
a bracketed character class), means any one character, including a space.
When used, it means "match one character", but there must be a character or
else the match will fail. For example, the regex .... will not match the input
string sip because "sip" has only 3 characters. The exception to this is when
the dot is followed by a star, question mark, or a brace pair if the brace pair
starts with the number 0. Inside a bracketed character class [], or proceeded by
a '\' backslash, the dot means the literal character (a period).

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-54

 Advanced HMR on the Net-Net SD

The Star and Plus signs

The '*' star, when treated as a special character (which is anytime it's not inside
a bracketed character class), means to match zero or more of the preceding
character, bracketed character class, or parenthesized group. For example a
regex of a* matches the input string of aaa-bob for aaa, but also matches hi-
bob because 'a' appears zero times, and even successfully matches hiyaa-bob,
but matches it with no characters, since 'a' appears zero times right at the start.
Typically one uses a dot before a star, as in .*, to mean "match any character,
zero or more times".
The '+' plus, treated as a special character (which is anytime it's not inside a
bracketed character class), means one or more of the preceding character,
bracketed character class, or parenthesized group. For example a regex of a+
matches the input string of aaa-bob for aaa, and matches hiyaa-bob for the aa,
but does not match hi-bob because 'a' does not appear one or more times.
Typically one uses a dot before a plus, as in .+, to mean "match any character,
one or more times". A plus is also "greedy", which will be discussed later.

TechNote: This '*' star usage is misunderstood by many people, as it

successfully matches an empty input string and because regex engines are
"greedy", which will be discussed later.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-55

 Advanced HMR on the Net-Net SD

The Vertical Pipe

The '|‘pipe, bar, is also called an alternation, when treated as a special
character (which is anytime it's not inside a bracketed character class), means
anything to the left or the right of it must match. Both sides of an alternation are
not always tried - first the left side pattern is tried, and only if it does not match
is the right side tried. For example, a regex of sip|sips will match the sip in
<sips:[email protected]>, not the sips, because the left hand side of the
alternation is successful. Alternation has the lowest order of preference among
all special characters. This means you don’t have to group a left or right-hand
side pattern.; For example (sip)|(sips) is not necessary.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-56

 Advanced HMR on the Net-Net SD

The Square Brackets

The '[' left bracket, treated as a special character, begins a bracketed character
class, enclosed by a ']' right bracket. A character class represents a list of
character options, meaning one and only one of the characters in the bracketed
character class must appear. If a '-' dash appears between two literal
characters, then it represents a range of characters, of which one and only one
must appear. For example, the regex [a-zA-Z0-9] means a single character
between the range 'a' through 'z', 'A' through 'Z', or '0' through '9' must appear
for the regex to match. When the first character after the '[' left bracket is a '^'
caret, then the class is negated, meaning the characters and/or ranges inside
the character class are the ones that will NOT match. For example the
character class [^0-9] means match a single character that is not in the range
'0' through '9'. The regex abc[^0-9] does not match abc, because there needs to
be a character not in the range '0' through '9' after the character 'c'. The only
exception to this is if the character class is made explicitly optional by being
followed with the '?' question mark, '*' star, or a braced interval such as {0,}.
The ']' becomes special, in that it terminates the bracket pair character class,
unless it immediately follows the '[' left bracket, or immediately follows a '^'
caret immediately following the '[' left bracket. If the ']' right bracket immediately
follows the '[' left bracket, or immediately follows a '^' caret which immediately
followed the opening '[' left bracket, then it does not enclose the character class
and is instead a literal character.

TechNote: A common mistake made is forgetting that a bracketed character

class is not optional - a character MUST be matched, even if the character

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-57

 Advanced HMR on the Net-Net SD

class is negated by the caret.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-57

 Advanced HMR on the Net-Net SD

The Round Brackets

The '(' left parenthesis, when treated as a special character (which is anytime
it's not inside a bracketed character class), creates a grouping, enclosed by the
')' right parenthesis. A grouping performs two roles: it separates pattern strings
so that the whole string can have a '*' star, '+' plus, '?' question mark, or braced
interval range applied to it, as if it were a single character, and it allows the
separated pattern to be stored and referenced later separately from the rest of
the regex match. The first role is similar to that done by parenthesis in
mathematics; a mathematics expression of x+y2 is very different from (x+y)2.
Likewise, a regex of abc* is very different from (abc)*. The former means
match an 'a' followed by a 'b' followed by zero or more 'c' characters, whereas
the latter means match the pattern "'a' followed by 'b' followed by 'c'" zero or
more times. The first regex abc* would match ab, but the other (abc)* would
not.
The parenthesized grouping's second role allows the user to define pieces of
the pattern which can be referenced later, if matched. For example if a regex of
^\+([0-9]*);cic=([0-9]*)$[1] is applied to the input string
+17813284400;cic=12345, the entire regex matches the entire input string of
+17813284400;cic=12345, the first sub-group matches 17813284400, and the
second sub-group matches 12345. This is used by the Net-Net SD for later
regex stored value reference.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-58

 Advanced HMR on the Net-Net SD

The Caret
The '^' caret, treated as a special character (which is anytime it's not the first
character inside a bracketed character class), is an anchor, representing the
beginning of the string. Used at the beginning of regex patterns, carets are
very useful in increasing performance by not letting the regex engine try a
pattern at all subsequent character positions - other than the first one. When
the caret appears as the first character inside a bracketed character class, i.e.
immediately following the '[' left bracket, it makes the character class the
negation of the characters following the caret.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-59

 Advanced HMR on the Net-Net SD

The Dollar Sign

The '$' dollar sign, treated as a special character when it's not inside a
bracketed character class, is an anchor representing the end of the string.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-60

 Advanced HMR on the Net-Net SD

The word boundary

The word boundary matches the position at the beginning and at the end of a
word. You can think of them as word-based versions of ^ and $ that match the
position at the start and end of a word, respectively.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-61

 Advanced HMR on the Net-Net SD

The Squiggly Brackets

The '{' left brace, treated as a special character when it's not inside a bracketed
character class, begins an interval range that is completed by a '}' right brace.
An interval range identifies how many times the previous single character or
parenthesized group must repeat. The syntax of an interval range is {min,max},
where the character or parenthesized group preceding the interval range must
appear min times up to max times. For example, a regex of a{2,3} applied to
hiyaa-bob will successfully match aa because it appeared at least twice. It will
also match the first aaa in hiyaaaaaa since that is 3 times of 'a'. An interval
range can also be expressed as {magnitude}, where the magnitude is exactly
the number of times the character must appear (i.e., as if min=max), or it can
be expressed as {min,} without the max, meaning the character must appear at
least min times or more. A '*' star is essentially a shorthand form of the interval
range {0,}, a '+' plus sign is the shorthand for {1,}, and a '?' question mark is the
shorthand form of {0,1}.
This confuses many people. The rule a{2,3} says to match a character of 'a' 2
or 3 times, which the regex engine does when it matches the aaa in hiyaaaaaa.
If you wanted the regex to match ONLY if there were 2 or 3 'a' characters but
no more, the regex for that would be something like ^[^a]*(a{2,3})[^a]*$.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-62

 Advanced HMR on the Net-Net SD

Regex backslash commands

When a “\” backslash is before a “special character”, it makes it no longer special, but just literal
(e.g., “\.” matches a period). When a backslash is before a backslash, it makes it match a literal
“\” backslash in the input string

Other than this, when a backslash is before a normal character, it means another command:
\, = match any character, including carriage-return or linefeed
\b = match the spot between a word character, and a non-word one
\B = match the spot between two word characters, or between two non-word characters
\d, \w, \s = match a digit, word character, whitespace respectively
\D, \W, \S = match the opposite of the characters of \d, \w, \s
\r, \n, \f, \t, \v = match carriage-return, newline, form-feed, h-tab, v-tab
\R = match either \r or \n or both together \r\n

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-63

 Advanced HMR on the Net-Net SD

How the Regex Engine Works

Regex engines of the type implemented by the Net-Net SD are performed from
left to right, starting at the position before the first character of the input string,
matching to the first character of the regex pattern. This is often
misunderstood: a regex engine can be in positions between, before, or after
characters in the input string. For example the '^' caret of the regex pattern
actually matches to the first position of the input string, which is before the first
actual character. Likewise the '$' dollar sign anchor actually matches the
location after the last character of the input string.
The regex engine looks at its current position in the input string, at the current
regex pattern command it’s at, and tries to match them. If they match, it moves
one position to the right in the input string, and possibly to the right one regex
command.

TechNote: regular expression "engine" is a piece of software that can process

regular expressions, trying to match the pattern to the given string. Usually, the
engine is part of a larger application, and you do not access the engine directly.
Rather, the application will invoke it for you when needed, making sure the right
regular expression is applied to the right file or data.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-64

 Advanced HMR on the Net-Net SD

How the Regex Engine Works (Continued)

For example, a regex of .*[0-9] with an input string of abc123 has the regex
engine start at the position before the 'a'. The regex engine starts at the regex
pattern command of .*. This means "match any character zero or more times".
Since the position before the first character 'a' is not a character, the regex
engine moves one position over and now points at the 'a' itself. The input
character 'a' is a character, so the regex engine accepts it as matching the .*,
and saves this position in case it has to backtrack later. It continues and moves
one position to the right in the input string, now pointing at the 'b'. This also
matches .*, so once again it consumes this character in the matching result,
saves the position in case it has to backtrack, and moves right one more
position to the 'c'. The same thing happens here. Now the regex engine is
looking at the '1', which once again matches the .* - this is something many
people don't understand: a "." is any character, including alphabetic characters,
digits, punctuation, spaces, etc. So the regex engine consumes the '1' as
matching the pattern, saves the position, and moves right once again. This
continues until it reaches the position after the last input character, namely the
position after the '3'. At this point the input string position no longer matches
the .*, so the engine moves right one regex pattern command and finds a [0-9]
bracketed character class. The regex pattern is not successful, because the
bracketed character class must match a character, namely any one character in
the range '0' through '9'. Because it does not match, the regex engine
backtracks, by going back one position in the input string and giving up the last
consumed character of '3'. The regex engine now checks if [0-9] matches the
'3', which it does, and the regex is done. The regex has now matched the input
string, with the matching result of abc123, NOT abc1 as some people
mistakenly assume.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-65

 Advanced HMR on the Net-Net SD

How the Regex Engine Works (continued)

In this example, a greedy quantifier * will force the engine to gobble as many characters
as possible until the end of the sentence, ending the first sub-match right after the word
Italian. From that point on, the engine will backtrack to the “ right after eels. The result of
the match will be THAT “Beverly Hills” is pronounced “beverlee eels”.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-66

 Advanced HMR on the Net-Net SD

Topic Review: Regex

What is backtracking?
The regex engine will search in reverse order to give back characters
taken during a greedy match.

What does the caret ^ do?

The caret matches the position before the first character in the string. It
also marks the start of the string and makes a negation of the
character/s that follows the ^.

The squiggly brackets {…} define a _________ or ________numerical range of

characters contained in a class. (fill in the blanks)
Minimum or maximum

The _________ brackets make backreferences.

Round (…)

Define back-references.
A back-reference stores the part of the string matched by the part of the
regular expression inside the parentheses.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-67

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-68

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-69

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-70

 Advanced HMR on the Net-Net SD

Introduction to regex HMR

The Net-Net DocSet Configuration Guide along with the ACLI Guide is an
excellent source for defining the fields in rulesets. In addition, the release notes
should also be reviewed to ensure you’re up-to-date on all the HMR and regex
features available in your release.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-71

 Advanced HMR on the Net-Net SD

A Simple Case
This HMR introduces regex in its body. Notice that comparison-type is pattern-
rule and that the match-value field contains a regex. If we match a string <tel at
the beginning of the line then we remove the P-Associated-URI header
altogether.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-72

 Advanced HMR on the Net-Net SD

Store and Match-value in Regex

Although HMR rule-sets are stateless, in the sense that they do not store
values across messages nor remember what they did in previous messages,
they can store strings for use within the same sip-manipulation rule-set. In
other words, some HRs and ERs can store values that later HRs or ERs can
use. Once the set of HRs and ERs in a sip-manipulation are performed and the
sip-manipulation is complete for the message, the stored values are forgotten.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-73

 Advanced HMR on the Net-Net SD

Comparison-type in regex HMR

The comparison-type for regex match-value is "pattern-rule", although
technically, since the action is "store“, the comparison-type is assumed to be
pattern-rule. If the match-value references a Boolean (true or false), then the
comparison-type value would be Boolean. If it were a different action type, and
one wanted simply a string to match against, you could use "case-sensitive" or
"case-insensitive" comparison-types.
The Integer operator will first perform a string to integer conversion of each side
since it does not make sense to perform string comparisons of those operator
types. If the string to integer conversion fails, the value will be treated as 0. So if
"$foo" is used in "$foo <= $bar" and $foo resolves to something stored that
cannot be converted to an integer, then it's treated as the number 0. Usually
you would use these integer operators when you've stored either phone
numbers or port numbers and want to test them against a fixed number, for
example (or in the future in ISUP-related type objects).
All of the above operators can be used in conjunction with the "!", "&" and "|“,
can be grouped in parenthesis, etc. They all return TRUE/FALSE as Booleans
would. You can use them with $variables or even just strings. For example
"$getPhone.$0 <= 10000" would resolve to TRUE if the stored value of some
rule name "getPhone" were an integer less than 10000 while "$getPhone.$0 ==
10000" would be TRUE if the stored value of a rule name getPhone were the
string 10000 (which means the same thing as the integer 10000).

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-74

 Advanced HMR on the Net-Net SD

Boolean Results in HMR

When HRs or ERs regex matches are performed, the Boolean result is TRUE if
the regex pattern match-value succeeded in matching, or FALSE if it did not.
This Boolean result can be used later in other HR or ER match-values to decide
whether to perform another action or not. For example, if an ER stored a uri-
parameter with a regex of .+, and the uri-parameter did not exist, the Boolean
result for that ER is FALSE, and a later HR or ER can check that before
performing an action. Boolean values of HRs and ERs are references in a
similar manner to their stored regex matched strings, except without the last
".$group_number" part. Therefore the following are the correct formats for
referencing the Boolean value of a previous HR/ER regex match:
• $header_rule_name
• $header_rule_name.$element_rule_name
• $header_rule_name[number]
• $header_rule_name[number].$element_rule_name
• $header_rule_name[~]
• $header_rule_name[~].$element_rule_name
• $header_rule_name[^]
• $header_rule_name[^].$element_rule_name
• $header_rule_name[*]
• $header_rule_name[*].$element_rule_name

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-75

 Advanced HMR on the Net-Net SD

Store and Match-value in Regex (continued)

For example, if the regex pattern ^([^;]+);(.+)$ were the match-value of an HR
named rgxTest, the entire regex matching string trunk-123;core would be
referenced in the new-value of another HR or ER using $rgxTest.$0; the first
group within the regex trunk-123 would be referenced by $rgxTest.$1; the
second group core would be referenced by $rgxTest.$2.
If the regex pattern were instead the match-value of an ER named rgxVal in the
HR rgxTest, then the whole matched string trunk-123;core would be referenced
by $rgxTest.$rgxVal.$0; the first group within it trunk-123 would be
$rgxTest.$rgxVal.$1, and the second group core would be referenced by
$rgxTest.$rgxVal.$2.
If the entire regex pattern does not match the input string, then nothing is
stored, even if a sub-group did match. For example if the input string for the
above regex were only trunk-123, or trunk-123;, then nothing would be stored
because the regex pattern did not match, even though the first sub-group would
have matched.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-76

 Advanced HMR on the Net-Net SD

Store and Match-value (continued)

In some cases, it's possible that there are multiple SIP headers in the message
of the same name, for example Route or Via headers, thus an HR for that
header-name would be performed multiple times. If the
$HR_name.$ER_name.$number syntax is used for referencing a stored value
for such a case, the value referenced would be that of the first such header in
the message. If one wants to reference a particular header, the following
syntax can be used:
$header_rule_name[number].$element_rule_name.$group_number
- Where the "number" is replaced by the number of the header in order
it appears in the message.
Or:
$header_rule_name[~].$element_rule_name.$group_number
- Where the "~" means the first header. This is equivalent to using a
number of "0" or the syntax without the "[ ]".
Or:
$header_rule_name[^].$element_rule_name.$group_number
- Where the "^" means the last header in the order in the SIP message.
Or:
$header_rule_name[*].$element_rule_name.$group_number
- Where the "*" means all the headers in the SIP message.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-77

 Advanced HMR on the Net-Net SD

Test-pattern-rule
The Net-Net SD supports a new command that allows you to test the regular
expression that you might use in SIP manipulation rules to see if it yields the
results you require. This command is useful for testing the regex values that
you devise because it will tell you whether that value is valid or not. This new
command is called test-pattern-rule, and you can access it through the ACLI’s
session-router path.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-78

 Advanced HMR on the Net-Net SD

Test sip-manipulation Example:

training1(test-sip-manipulation)# sip-manipulation DELETE_ADD
training1(test-sip-manipulation)# execute
After Manipulation[DELETE_ADD]

INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.60:5060;branch=z9hG4bK4odk1f20a8g0gdcln7c0
From: sipp <sip:[email protected]:5060>;tag=9hqq601-15329
To: sut <sip:[email protected]>
Call-ID: 9hqq601-45ad705ceba52d6aed059f6fb0ad3bbb-06a3gu0
CSeq: 1 INVITE
Contact: sip:[email protected]:5060
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 169
P-HEADER: 192.168.1.61

v=0
o=user1 53655765 2353687637 IN IP4 192.168.1.60
t=5 2
c=IN IP4 192.168.1.60
m=audio 10000 RTP/AVP 0 22
a=rtpmap:0 PCMU/8000
a=rtpmap:22 G728/8000
a=ptime:10

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-79

 Advanced HMR on the Net-Net SD

Example regex HMR

This HMR replaces the uri-display parameter value of the P-Asserted-Identity
header with the value of the uri-display parameter of the contact header.
The value of the contact uri-display is stored first. Notice the blank match-value
in the element-rule getName. Blank in this case means .+ which means match
at least one character, as many times as possible. Whatever we store in the
CONTACT HR/ER pair gets referenced in the P-Asserted-Identity HR/ER pair,
by setting the value of the match-value parameter to $getContact.$getName.
This reference is set to Boolean by the comparison-type field. If the match is
TRUE (and in the case we match at least 1 character in the contact uri-display
field it is true) then the new value of the PAI uri-display is replaced by the entire
value of the contact uri-display ($getContact.$getName.$0)

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-80

 Advanced HMR on the Net-Net SD

A False Boolean Case

In this HMR we perform an action for a Boolean result of FALSE.
In the matchFROMvalue we specify the regex ^\+39(046[7-9], which means we
only want to match calls coming from +390467, +390468 or +390469. Numbers
that don’t match (!$rgxmatchFrom.$matchFROMvalue) will be blacklisted by
adding a ROUTE header pointing nowhere (0.0.0.0)

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-81

 Advanced HMR on the Net-Net SD

SDP Manipulation
Using the SIP HMR feature set, you can manipulate MIME types in SIP
message bodies. While you can manipulate the body of specific content type
using other iterations of SIP HMR, this version gives you the power to change
the MIME attachment of a specific type within the body by using regular
expressions. To achieve this, you use the find-replace-all action type, which
enables the search for a particular string and the replacement of all matches for
that type. To manipulate a particular portion of the MIME attachment—as in
removing a certain attribute within the content type of application/SDP—the
Net-Net SD would need to search the content multiple times because SDP can
have more than one media line, and the SIP message body can contain more
than one application/SDP.
The find-replace-all action type works for SIP header rules and for element
rules. You can use it for all manipulation types from the entire header value, to
the URI specific parameters, to MIME attachment. SIP HMR’s support for
escape characters allows for searches for values you would be unable to enter
yourself. Because they are necessary to MIME manipulation, support for
escape characters now includes:
• \f
• \n
• \r
• \t
• \v

TechNote: Note that using find-replace-all might consume more system

resources than other HMR types. Therefore this powerful action type should
only be used when another type cannot perform the type of manipulation you
require.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-82

 Advanced HMR on the Net-Net SD

Useful for SDP manipulation:

You can indicate the sub-group replacement syntax by adding the string [[:n:]]
to the end of the regular expression—where n is a number between 0 and 9.
For example, given the following settings:
• action=find-replace-all
• match-value=sip:(user)@host[[:1:]]
• new-value=bob

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-83

 Advanced HMR on the Net-Net SD

HMR Tips for SDP

The below rule is aiming to Store the m= line associated to t38, as well as all the a= lines that are
associated with it. We could use two options here:
a) match-value m=image 0 udptl t38.*
In this case, only the m= line will be matched, as the . character in Regex, does not include CR or LF
b) match-value m=image 0 udptl t38\,*
In this case All lines included in the sdp-media-rule will be stored
mime-sdp-rule
name StoremlineWithAllalinesAssociated
msg-type any
methods
action manipulate
comparison-type case-sensitive
match-value
new-value
sdp-media-rule
name storet38
media-type media[0]
action store
comparison-type pattern-rule

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-84

 Advanced HMR on the Net-Net SD

match-value m=image 0 udptl t38.*

\,*
new-value

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-84

 Advanced HMR on the Net-Net SD

New elements for SDP manipulations with Release 6.3

Those new elements allow a lot more flexibility in the way we can work with manipulations
inside the SDP Body of a message. They allow to identify, group and perform changes to
individual lines, group of lines or all the Atributes related to a particular type of media, voice,
video, fax, etc.
See a few examples in the previous page notes and the next page notes area.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-85

 Advanced HMR on the Net-Net SD

Understanding SDP parts for HMR new elements

sip-manipulation
name Generalmanip
mime-sdp-rule
name removePtime
msg-type any
action manipulate
comparison-type case-sensitive
sdp-media-rule
name removePTimes
media-type audio
action manipulate
comparison-type case-sensitive
sdp-line-rule
name removePTime
type a
action delete
comparison-type pattern-rule
match-value ^ptime

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-86

 Advanced HMR on the Net-Net SD

The above rule removes the a=ptime inside the SDP Body

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-86

 Advanced HMR on the Net-Net SD

Hidden SIP headers

As of C630, the Net-Net SBC supports the concept of hidden SIP headers

Hidden headers are prefixed with the “at” symbol, @

On egress, these headers do not pass the SIP parser checks and are therefore not sent out to
the next-hop – removing the need for cleanup SIP manipulations

Since “@” is not a valid character in a header name (see RFC 3261), there is no possibility of a
collision between a header name defined in the future and a hidden header name beginning with
“@”

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-87

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-88

 Advanced HMR on the Net-Net SD

HMR for XML

The Net-Net SD can perform specific actions other than just delete an XML Body
contained inside a SIP Method. It can NAT to avoid topology leaking or modify the
content or even reject and log if it finds specific content on it.
The Net-Net SD performs the NAT to the <deviceID> XML tag only if it is configured to
perform registration caching.
When the Net-Net SD receives a SIP message from the core side and the request has:
• A Content-Type of application/csta+xml
• A Content-Length greater than 0
It parses the message’s message body into an XML document. Should parsing fail, the
Net-Net SD will forward the SIP INFO request without modification to the XML message
body. Otherwise, the Net-Net SD searches for the <deviceID> sub-element within the
XML document. If it finds the <deviceID> sub-element, the Net-Net SD searches
through its registration cache for a registered Contact that matches the value of the
<deviceID>. If it finds a match, the Net-Net SD replaces the value of the <deviceID>
with that of the corresponding registered Contact. If the value of the <deviceID> is a
Contact that the Net-Net SD generates for a registered UA, the corresponding contact
from the look-up would be the Contact of the registered UA. Once these functions have
been performed, the Net-Net SD reformats the SIP INFO request with the modified XML
message body before sending it to the next hop. If there is no match found, the Net-Net
SD forwards the SIP INFO request without modifying the XML message body.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-89

 Advanced HMR on the Net-Net SD

HMR for ISUP overview

The Net-Net SD’s HMR functionality can operate on ISDN user party (ISUP)
binary bodies. Using the same logic and mechanisms that are applied to SIP
header elements, HMR for SIP-ISUP manipulates ISUP parameter fields and
ISUP message parts. You can create MIME rules that function in much the
same way the SIP header rules do; whereas SIP header rules can change the
specific headers of a SIP message, MIME rules can manipulate targeted body
parts of a SIP message.
MIME ISUP manipulation supports performing HMR operations on SIP ISUP
binary bodies and is configured in the mime-isup-rule configuration. This
configuration works the same way that the MIME rule configuration does and
contains the same parameters for you to set, but it also includes additional
parameters and a sub-configuration targeted specifically for ISUP application.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-90

 Advanced HMR on the Net-Net SD

HMR for ISUP (continued)

• isup-msg-type—Refers to specific ISUP message types, such as Initial
Address Message (IAM) and Address Complete Message (ACM), that the
Net-Net SD uses with the msg-type parameter (which identifies the SIP
message) in the matching process. You enter values in this parameter as a
list of numbers rather than as an enumerated value because of the large
number of ISUP message types, with a range between 0 and 255.
• isup-spec—Specifies how the Net-Net SD is to parse the binary body; valid
values are the enumerated type. The values for this parameter are these
SIP ISUP formats:
• ANSI-2000—Corresponding to ANSI T1.113-2000
• ITU-99—Corresponding to ITU Q.763
Because ISUP messages do not identify their format, you must designate
which you want to use.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-91

 Advanced HMR on the Net-Net SD

HMR for ISUP- (continued)

• isup-parameter-rules (sub-configuration)—If you are familiar with HMR,
think of this parameter as being similar to the element-rule for a SIP header-
rule. You use it to create, manipulate, and store different parameters in the
body of the ISUP message. Two parameters for this rule are unique:
parameter-rule and parameter-format.
• parameter-type—Using ISUP parameter mapping, this setting identifies on
which of the ISUP parameters you want to perform manipulation. This
parameter takes values between 0 and 255, and you must know the correct
ISUP mapping value for your entry. The Net-Net SD calculates the offset
and location of this parameter in the body.
Note that the value returned from the body does not indicate the type or length,
only the parameter value. For example, a parameter-type value of 4 acts on
the Called Party Number parameter value. In accordance with the ISUP
specifications, only certain message types are allowed to have optional
parameters. If optional parameters are present, an offset field must exist for
them; so its value is 0 even if there are no optional parameters in the SIP
message. For example, if you define a SIP ISUP rule that applies to all
message types and adds a parameter that is neither fixed nor variable, The
Net-Net SD adds it as an optional parameter regardless of whether that
message type should not support optional parameters.
If you define an ISUP parameter rule with an add action and an empty new-
value, the Net-Net SD uses the default for that parameter. If you define an ISUP
parameter rule with a replace action and no parameters exist, the Net-Net SD
will not perform any action. This behavior is consistent with that of SIP header

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-92

 Advanced HMR on the Net-Net SD

rules in that a value can only be replaced if it already exists. If there is a value and no
new value is set, the Net-Net SD sets it as a zero-length parameter.
(continued on next page)

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-92

 Advanced HMR on the Net-Net SD

• parameter-format—This parameter converts the specific parameter to a

string representation of that value. Valid values for parameter-format are:
• number-param, hex-ascii (default), binary-ascii, ascii-string, and
bcd.
Both match and new values are encoded and decoded by the designated
parameter-format type. In this regard, the match-value decodes the parameters
and the new-value encodes the ASCII string into the respective binary format.
Note that if you enter a new-value setting larger than the size of the parameter,
the Net-Net SD will perform no operation and will generate a corresponding
error log message.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-93

 Advanced HMR on the Net-Net SD

HMR for ISUP – (continued)

You can configure a SIP header manipulation to add an ISUP body to a SIP message
and the Net-Net SD will add them after any SDP parts if they are present. You can add
an ISUP body to a SIP message in two ways:
• You can create a mime-isup-rule with the action type set to add and enter
the entire body in string hexadecimal form in the new-value parameter.
• You can leave the new-value parameter empty at the mime-isup-rule level
and create an add rule for an isup-param-rule.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-94

 Advanced HMR on the Net-Net SD

Parameter format number-param

• number-param As the decimal value of the specified number type, treats
the parameters as a generic number parameter type. For example, a
parameter-type 4 acts on the Called Party Number parameter.
When the action type is replace or add, the Net-Net SD automatically sets the
parameter’s odd-even bit based on the number being inserted in relation to the
new-value setting. If the Numbering Plan Indicator bits are 0b001 (ISDN,
E.164), then the Net-Net SD sets the Nature of Address field to 0b0000100
(international). If this number type is added to a non-existent parameter field,
then the Numbering Plan Indicator field is 0b0000011 (national number). If this
number type is added to a non-existent parameters field, then the Numbering
Plan Indicator field will be set to 0b001 (ISDN,E.164) and the Net-Net SD will
also follow the previous rules.
Regardless of the action type you set, the string represented for match-value
use for this type will be the numbers of the address fields after the BCD coding.
There will be a leading plus sign (+) if the Number Plan is 0b001 and the Nature
of Address is 0b0000100 ((international); otherwise, there will not be a plus sign
(+).
If it cannot convert the data field to a number parameter, the Net-Net SD will
return an empty string. And if the new-value is not a number or cannot fit in the
specified parameter type field, the Net-Net SD takes no action.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-95

 Advanced HMR on the Net-Net SD

Encode/decode format bcd format

In ISUP speak, BCD (Binary Coded Decimal) refers to the binary format of the
number used as a half a byte nibble, with the byte’s lower nibble containing the
first digit and the higher nibble containing the second digit. For example, the
number 127 is encoded as the two binary bytes 0x2107 on the wire.
Using this mode, the Net-Net SBC treats the binary ISUP content as BCD; it
should decode it from 0x2107 to the string 1270, and from a string of 127 it
should decode it as 0x2107.
Since a byte has two nibbles, a nibble might have to be added. And when the
Net-Net SBC performs decoding, it cannot know that a BCD byte represents
one or two ASCII digits—so it assumes there are two. The number-param
setting decodes the parameter as a common number parameter. The Net-Net
SD sees the odd/even bit as in the first bite as telling it how many nibbles to
decode correctly, and it will set the odd-even when it decodes.
Non-binary digit characters fail to match against the body part if they are
contained in the match value, and non-binary characters in the new value
result in no operation being performed.

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-96

 Advanced HMR on the Net-Net SD

Topic Review: Advanced HMR

If the entire regex pattern does not match the input string, then what is stored?
Nothing is stored, even if a sub-group did match.

To store and retrieve values within a regex ruleset, which HR/ER parameter
should be set to store?
Action parameter

If you want to condition an action to a previous match, how would you do it?

Using comparison-type boolean and in

the match-value
$header_rule_name.$element_rule_name
What does the ^ mean in this example?
$header_rule_name[^].$element_rule_name.$group_number
The last header

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-97

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-98

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-99

 Advanced HMR on the Net-Net SD

Copyright © 2012 Acme Packet, Inc. ahmr.6.j.pm-100

admh.6.j.pm-0
Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-1

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-2

Advanced Media Handling

Media Handling Principals

To handle (manage) media with the Net-Net SD, you need to properly configure
the media-manager, which is the global element for handling media. The
media-manager defines the general behavior and some generic parameter
values related with the media flows. Such behaviors include latching, which is
the ability to recall the source IP address and port of the first packet and use it
as a restriction for the rest of the packets in this flow.
There are also three important timers you should consider configuring
including:
• flow-time-limit - indicates the maximum duration of the flow
• initial-guard-timer - the time the Net-Net SD waits for the first packet
before releasing the flow and the call
• subsequent-guard timers - the time the Net-Net SD waits after
receiving the first RTP packet
There are many other parameters, some of which will be discussed later in this
module.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-3

Advanced Media Handling

Conceptualizing the Session Director

It’s easiest to think of the Net-Net SD as encompassing multiple networks
providing edge proxy (signaling and media) functions between them. The
external networks and internal networks are linked by way of an edge proxy
function for SIP signaling, providing access to the SIP B2BUA function. The
Media NAT/Relay Function provides RTP and RTCP NATting and forwarding
as well as access control functions.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-4

Advanced Media Handling

When to handle or release media

There are four manage-media-in (mm-in-…) parameters in the realm element that affect
how the Net-Net SD handles media for a particular session. These are listed on the
slide. The list indicates decreasing specificity in terms of the checks the Net-Net SD
uses to decide how to handle the media.
• mm-in-system - If you disabled mm-in-system, all calls will release media for this
realm, unless the connected realm is configured to handle it.
• mm-in-networks -This is for calls inside the same network-interface (VLAN).
• mm-in-realm – This is for calls inside the same realm.
• mm-in-same-ip – This lets the Net-Net SD release media when two endpoints are
behind the same IP address, in the same realm. Using this feature prevents the
media for intra-site calls from going through the Net-Net SD. You can also use this
feature for both hosted NAT traversal (HNT) and non-HNT clients. It works with
NATted endpoints and for non-NATted ones that are behind the same IP.

You can now configure your Net-Net SD to release media between endpoints sharing
the same NAT IP address, even if one endpoint is at—but not behind—the same NAT.
This feature is activated by adding the option “release-media-at-same-nat”, which
expands the Net-Net SD’s ability to release media between calling and called parties
behind the same IP address/NAT device in the same realm or network.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-5

Advanced Media Handling

Manage Media optional values

This is a printout of the realm element configuration where the mm-in-
parameters are set. Remember that both the ingress and egress realm
determine media handling.

TechNote: Any mm-in- parameters set to enabled will take precedence over
those set to disabled, e.g. mm-in-system disabled for peer1 and enabled for
peer2 will make the Net-Net SD handle the media.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-6

Advanced Media Handling

Media Handling examples

In the first example, both endpoints originating and terminating the call are
members of the same realm. Therefore the Net-Net SD looks at the value of the
mm-in-realm. If it is set to its default value (disabled), the media is released.
In the second case, both endpoints are behind the same NAT. Note that even if
the parameter mm-in-realm is enabled, the system will also check the mm-in-
same-ip value and, if set to disabled - then media will be released.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-7

Advanced Media Handling

Media handling examples

The third example shows two different realms for ingress and egress, but the
same network-interface for both. Therefore, the parameter mm-in-network must
be checked in both realms, and if it is enabled in at least one of them, media
will be handled by the Net-Net SD.
In the last example, we have different realms and different network-interfaces.
Here, the Net-Net SD refers to the mm-in-system parameter to decide if it
should control the media.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-8

Advanced Media Handling

Media Processing
RTP Processing is entirely hardware-based (the Host subsystem is not
involved). Received RTP packets are treated in the same way as signaling
packets in the Network Processor subsystem, with one exception—CAM
lookups must yield exact matches, or the RTP packet is dropped. These exact
match entries are instantiated by the Host Subsystem based on successful call
setup signaling.
All these are processes are handled within the network processors, so they do
not impact the performance of the CPU in the host subsystem. It is
recommended to use both physical interface slots (M00 and M10) because the
network processors are linked one to one. Therefore, the use of both network-
processors increases the overall performance.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-9

Advanced Media Handling

MBCD Overview
The Middlebox Control Daemon (MBCD) is the common interface between the
application layer (the VoIP protocol stacks such as SIP, H.323, and MGCP) and
the hardware. It creates, modifies and removes flows, which are the
fundamental unit of a multimedia session.
MBCD, also known as the MIBOCO daemon is based loosely on Megaco
(H.248) version 1.0, as designed by the IETF. The three atomic operations
supported by MIBOCO are add, subtract, and modify.
As signaling messages are received by the application layer of the Net-Net
4250 (the session router), messages that create, modify, or delete interactive
multimedia sessions (e.g., RTP) are handed off to the media layer (the media
manager) to establish NAPT forwarding rules (NAT entries) in the CAM.

TechNote: The original design of the Net-Net 4250 was decomposed into two
physical boxes; Session Router and Media Manager. The session router
elements and media manager elements are directly mapped in our ACLI
configuration hierarchy.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-10

Advanced Media Handling

MBCD Terminology
Contexts are collections (containers) of all of the data associated with a
multimedia session. Contexts contain one or more flows, which are
unidirectional streams of packets that travel from an origin to a destination,
traversing the Middlebox in the process. The media manager element of the
Session Director is the integrated Middlebox aspect of our design.
The MIBOCO protocol provides an interface for application protocols to operate
on individual flows (by referencing a FlowID) as well as all flows associated
with a multimedia session (by referencing a ContextID).
An example of an application command to act upon an individual flow may be to
put a flow on hold (disable packet forwarding by setting its forwarding mode to
off).

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-11

Advanced Media Handling

Miboco transactions call flow

1. Sipd receives a SIP Invite with an SDP offer from the caller and determines
the ingress and egress realm for this call.
2. Sipd then sends an add miboco message with a unique transaction ID to
mbcd telling it to create a new context with two flows. One flow should be
set from the ingress to the egress, and the other one should be from the
egress to the ingress network (realm) of the call. The Sipd also includes the
caller's remote IP address and port, used as the destination address of the
flow to the ingress side of the call. In this miboco transaction (which include
2 ADD flow commands), sipd requests a Context ID and the IP addresses
and ports on both sides of the SBC where RTP/RTCP traffic will flow in and
out.
3. Mbcd replies to the Sipd using the same transaction ID with one context ID.
Mbcd also replies with the local IP addresses and ports on both the egress
and ingress realms (extracted from steering pools associated to those
realms) where media will flow in and out.
4. Sipd can now send the invite with adapted SDP to the egress realm.
5. 6. and 7. The 200 OK is received with SDP of the called endpoint, so sipd
sends a modify transaction to mbcd to adapt the CAM entries and the
flows. Mbcd accepts it.
8. CAM entries are updated and can now proxy RTP and RTCP traffic.
9. 10. and 11. When the bye is received by sipd, sipd needs to inform mbcd to
liberate resources and stop forwarding RTP/RTCP. Sipd does this with a
subtract command, acknowledged by mbcd, which then deletes the CAM
entries.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-12

Advanced Media Handling

Building the NAT Entries

In order to properly route and translate media flows (NAT RTP headers), we
build tables in CAM that define classifiers (match criteria) and translation rules.
For a typical voice call, this would consist of two entries, one for each direction
through the Net-Net SD. These entries include:
• SA – Source IP Address of the received RTP packet (Populated if latching
enabled)
• SA_prefix – bit length of the required match, which is typically 32-bit (exact
match required)
• SP – Source port of the received RTP packet (Populated only if user behind
NAT)
• SP_prefix – bit length of the required match, up to 16 bits (often set to 15
bits to match RTP and associated RTCP packets)
• DA – destination IP address for the RTP packet (a steering pool IP address)
• DA_prefix – bit length of the required match
• DP – destination port (a steering pool available port)
• DP_prefix – bit length of the required match
• XSA – translated source IP address (steering pool IP address for the egress
realm)
• XSP – translated source port (steering pool port for the egress realm)
• XDA – translated destination IP address (the next hop media element IP
address)
• XDP – translated destination port (the next hop media element bound port)
• These entries are filled by MBCD add and modify transactions according to
information culled from dialog-creating transactions (e.g, INVITE and
associated 200 OK).

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-13

Advanced Media Handling

SIP Message and MIBOCO Transaction

This is an example of a received INVITE and the associated MIBOCO
transaction used to instantiate entries into CAM based on the received SDP.
The c line in the SDP indicates the target for media (where the originator of the
INVITE will be listening for RTP). This is is populated in the edest (egress
destination) for the westbound media flow (from ingress realm core to egress
realm access, as this call originated in the access realm). The m line in SDP
indicates, amongst other things, the UDP port number that will be bound for
receiving and processing RTP. This is populated in edest for the westbound
media flow (after the IP address, following a colon).
Process flow: Receiving the offer
A signaling message is received by an application protocol. The application
protocol parses the media offer (SDP, H.245) and constructs a MIBOCO Add
transaction. It assigns a unique TransactionID. The Add transaction includes all
information that the application has so far, including:
• Remote party’s IP address and port for receiving media
• Bandwidth required, based on advertised codecs (this is done by the
application)
• Ingress and egress realms
• The Add transaction includes choose and variable wildcards for information
• The message is sent to MBCD using a dedicated Service Socket

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-14

Advanced Media Handling

MBCD Processes the Request

MBCD creates a context and adds the flows to it. It selects media addresses
from the steering pools associated with the ingress realm. The number of
consecutive ports selected is defined by the num attribute in the flow request.
Next, the egress interface for the flow is decided for the flow based on the
realm. MBCD checks to ensure that the IP and port present in the Add request
don’t match one that was previously issued. If so, then the Net-Net SD will be
able to either hairpin or release the media depending on the configuration.
MBCD issues an Add transaction to instantiate the entry to the CAM. The
interaction between the session router and the media manager is roughly
analogous to the offer/answer model as described in RFC 3264; flows are
established upon receipt of an offer and modified upon receipt of an answer.
When a signaling message containing a media offer (SDP for SIP and
MGCP/NCS, H.245 for H.323) is received by the session router, the application
constructs a MIBOCO Add transaction.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-15

Advanced Media Handling

Examining CAM RTP NAT Entry Statistics

The show nat info command displays statistical information about CAM
utilization, including maximum number of entries and current usage.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-16

Advanced Media Handling

Examining CAM RTP NAT Entries

The show nat by-addr <Source IP> <Destination IP> command displays
specific CAM entries. Apart from the L3/L4 fields that we have described
earlier, SA_flow_key, SP_flow_key, DA_flow_key, DP_flow_key,
XSA_data_entry, XSP_data_entry, XDA_data_entry, XDP_data_entry, we see
specified inside the CAM entry the ingress and egress VLAN, slot and port as
well as the 3 timers relative to the media flows.
In releases prior to 6.2M4p2, the show nat by-addr command with no
addresses specified was dangerous as it was using the empty values as
wildcards and dumping all entries in the CAM. To give an entry by destination
address the command was: show nat by-addr 0 x.x.x.x
From release 6.2M4p2 and later, the command has changed to: show nat by-
addr 0.0.0.0 x.x.x.x

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-17

Advanced Media Handling

Releasing Media
In this particular case, the core softswitch releases the media. The Net-Net SD
also releases the media because of the manage media parameter settings in
the ingress and egress realms. Although the Net-Net SD creates 0 contexts
and no CAM entries, it does create 2 flows. The reason for the flows is to
reserve steering pool ports (media resources) in case the call needs them in a
later stage (i.e. a call forward, conference, etc).
Media release on the Net-Net SD proceeds as follows:
1. SD receives initial offer from caller.
2. SD allocates flows, writes CAM entry for forwarding packets to
caller, rewrites SDP, forwards to SS.
3. SD receives same SDP from SS that it sent in [2] – softswitch has
released the media; SD allocates flows and links them. Note that
this is a new session.
4. SD sends SDP from [1] to called – SD has released the media;
CAM entry is removed.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-18

Advanced Media Handling

Hairpinning Media
In this particular case, the core softswitch releases the media. The Net-Net SD
will handle media because of the manage media parameter settings in the
ingress and egress realms. It creates 1 context with 2 flows and 2 CAM entries.
Media hairpinning on the Net-Net SD with softswitch media release proceeds
as follows:
1. Net-Net SD receives initial offer from caller.
2. Net-Net SD allocates flows, writes CAM entry for forwarding
packets to caller, rewrites SDP, forwards to SS.
3. Net-Net SD receives same SDP from SS that it sent in [2] –
softswitch has released the media; SD allocates flows and links
them.
4. Net-Net SD rewrites SDP from allocated steering-pool port to called
– SD has anchored the media; CAM entry is preserved.
5. Net-Net SD receives SDP answer from called, updates flow and
writes 2nd CAM entry.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-19

Advanced Media Handling

Hairpinning Media
In this particular case, the core softswitch does not release the media, so the
Net-Net SD is going to handle it depending of the manage media parameter
settings in the ingress and egress realms (in this case the core realm where the
SS resides).
The Net-Net SD creates 2 context, each of them with 2 flows and 2 CAM
entries.
Media hairpinning on the Net-Net SD without softswitch media release
proceeds as follows:
1. SD receives initial offer from caller.
2. SD allocates flows, writes CAM entry for forwarding packets to
caller, rewrites SDP, forwards to SS.
3. SD receives same SDP from SS that it sent in [2] – softswitch has
released the media; SD allocates flows and links them
4. SD rewrites SDP from allocated steering-pool port to called – SD
has anchored the media; CAM entry is preserved.
5. SD receives SDP answer from called, updates flow and writes 2nd
CAM entry.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-20

Advanced Media Handling

Delayed Media Update

The Net-Net SD supports SIP delayed media update. When enabled, this feature keeps
the Net-Net SD from updating its media flow information for flows established after an
offer-answer exchange. The Net-Net SD does not update the flow information until a
new offer and answer arrive for a specific set of media flows. The (subsequent) offer
does not have to be for the same session; rather, it can appear as a new SIP INVITE
that uses the same SDP. This slide describes how the delayed media update feature
works for hairpinned call flows and for an SDP offer arriving for installed flows.
•Hairpinned call flows — In this type of call flow, the application server (AS) or
Softswitch sends an INVITE back to the Net-Net SD and that INVITE needs to be
forwarded to another user (called). When the Net-Net SD receives the offer in this
INVITE and delayed media update is disabled, the Net-Net SD determines that the call
is hairpinned and deletes the CAM entry for the flow for user A (caller), who has sent
the initial INVITE. The Net-Net SD deletes the CAM entry for the flow from the SS to the
caller. With delayed media update enabled, the CAM entry for the flow from the AS to
user A is not deleted. Instead, the Net-Net SD waits until it has an answer from user B,
and then performs the necessary updates and deletions.
•SDP offer for installed media flows — With delayed media update enabled, if it has
received an offer and answer and a new offer arrives for the same flow, the Net-Net SD
delays updating the CAM entries until an answer is received for the new offer.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-21

Advanced Media Handling

Call on hold
There are two main mechanisms of putting a call on hold. Depending on the RFC that
the endpoint follows, there could be a slight difference.
RFC 2543 (original SIP RFC depreciated by 3261) specifies:
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily
stop sending one or more media streams, a party re-invites the other by sending an
INVITE request with a modified session description. The session description is the
same as in the original invitation (or response), but the "c" destination addresses for the
media streams to be put on hold are set to zero (0.0.0.0).
RFC 3264 (An OfferAnswer Model with the SDP) specifies:
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily
stops sending one or more unicast media streams, a party offers the other an updated
SDP. If the stream to be placed on hold was previously a sendrecv media stream, it is
placed on hold by marking it as sendonly. If the stream to be placed on hold was
previously a recvonly media stream, it is placed on hold by marking it inactive. This
means that a stream is placed "on hold" separately in each direction. Each stream is
placed "on hold" independently. The recipient of an offer for a stream on hold SHOULD
NOT automatically return an answer with the corresponding stream on hold. An SDP
with all streams "on hold" is referred to as held SDP.
The Net-Net SD can work with both approaches and delete the flow towards the party
that put the call on hold and reset the timers on the other direction every time it receives
an RTP packet.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-22

Advanced Media Handling

Latching
Latching is when the Net-Net SD listens for the first RTP packet from any
source address/port for the destination address/port of the Net-Net SD (taken
from the steering pool). The destination address/port is allocated dynamically
and sent in the SDP of the answer (i.e. 200 OK). After it receives an RTP
packet for that allocated destination address/port, the Net-Net SD only allows
subsequent RTP packets from that same source address/port for that particular
Net-Net SD destination address/port. Latching does not imply that the latched
source address/port is used for the destination of the reverse direction RTP
packet flow (it does not imply the Net-Net SD will perform symmetric RTP).
Latching is a configurable behavior controlled by a property within the media-
manager element. It determines how the Net-Net SD reacts to dynamic flows
(signaling). When enabled, the SD will lock down a flow upon receipt of the first
packet at an allocated steering pool. The associated CAM entry is modified to
the source IP address of the RTP.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-23

Advanced Media Handling

Building the NAT Entries

In order to properly route and translate media flows (NAT RTP headers), we
must build tables in the CAM that define classifiers (match criteria) and
translation rules. For a typical voice call, this would consist of two entries, one
for each direction through the Net-Net SD.
Once those flows are instantiated in CAM entries, if latching is enabled, or the
endpoint is detected to be behind a NAT device, they wait for the first RTP
packet arriving to the announced destination for this flow. When the user is not
behind a NAT, only the source address will be populated. If the user is behind a
NAT, then both source IP and source port will be written.
Note: The source port is also populated during symmetric latching, which will
be explained later in this module.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-24

Advanced Media Handling

Latching Options
Latching is a global parameter, by default enabled, on the Net-Net SD. Note
there are further options under realm configuration covered later in the module.
When an offer or answer message is received by an application protocol such
as SIP, the media part (SDP for SIP) is parsed in order to construct a MBCD
Add or Modify transaction. This is because new media information may be
gleaned from the answer and needs to be appended to the CAM entry
instantiated by the initial Add transaction. When latching is enabled this is still
the case, but the IP and port will not be used for the destination if symmetric-
latching is enabled or the user is detected to be behind a NAT .

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-25

Advanced Media Handling

Restricted Latching
The restricted media latching feature lets the Net-Net SD latch only to media
from a known source IP address, in order to learn and latch the dynamic UDP
port number. The restricting IP address’s origin can be either the SDP
information or the SIP message’s Layer 3 (L3) IP address, depending on the
configuration. The Net-Net SD restricts latching of RTP/RTCP media for all
calls within a realm. It latches to media based on one of the following:
• SDP - the IP address and address range based on the received SDP c=
connect address line in the offer and answer.
• Layer 3 - the IP address and address range based on the received L3 IP
address of the offer or answer. This option is for access registered HNT
endpoints. If the L3 IP address is locally known and cached by the Net-Net
SD as the public SIP contact address, that information could be used instead
of waiting for a response. The Net-Net SD might use the L3 IP address
restriction method for all calls regardless of whether the endpoint is behind a
NAT or not, for the same realms. Enabling restricted latching can make the
Net-Net SD wait for a SIP/SDP response before latching, if the answerer is
in a restricted latching realm. This is necessary because the Net-Net SD
does not usually know to what to restrict latching until the media endpoint is
reached. The only exception could be when the endpoint’s contact/IP is
cached.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-26

Advanced Media Handling

Symmetric Latching
Symmetric latching is a mode where a device’s source address/ports for the
RTP/RTCP it sends to the Net-Net SD, that are latched, are then used for the
destination of RTP/RTCP sent to the device in the reverse flow. The current
forced HNT symmetric latching feature lets the Net-Net SD assume that
devices are behind NATs, regardless of their signaled IP/SIP/SDP layer
addresses. The Net-Net SD latches on any received RTP destined for the
specific IP address/port of the Net-Net SD for the call and uses the latched
source address/port for the reverse flow destination information. If both
restricted latching and symmetric latching are enabled, the Net-Net SD only
latches if the source matches the restriction, and the reverse flow will only go to
the address/port latched to, and thus the reverse flow will only go to an address
of the same restriction. You configure symmetric latching within a realm to one
of the following settings:
• enabled - the Net-Net SD sends the media in the opposite direction to the
same IP and port after it latches to the source address of the media packet.
• disabled - the Net-Net SD only latches the incoming source. The destination
of the media in the reverse direction is controlled by the SDP address.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-27

Advanced Media Handling

When to enable symmetric latching

In this example, signaling is coming to the Net-Net-SD from a PBX and not
directly from the endpoint, so the SDP information that comes in the original
Invite is not valid as it is the private IP address of the endpoint. Because we
enable symmetric-latching, the Net-Net SD will wait for the first RTP packet
received from the endpoint, and it will send RTP in the reverse direction to this
IP address and port. (Note that it will be the IP and port of the public side of the
NAT device.)
Another example of when to use the restricted-latching option is when a VoIP
service is provided using symmetric-latching. A B2BUA/proxy sits between
HNT endpoints and the Net-Net SD, and calls do not appear to be behind NATs
from the Net-Net SD’s perspective. The Net-Net SD’s primary role, in this case,
is to provide symmetric latching so that HNT media will work from the
endpoints. To ensure the Net-Net SD’s latching mechanism is restricted to the
media from the endpoints when the SIP Via and Contact headers are the
B2BUA/proxy addresses and not the endpoints’, the endpoint’s real (public) IP
address in the SDP of the offer/answer is used. The B2BUA/proxy corrects the
c= line of SDP to that of the endpoints’ public FW address. The Net-Net SD
would then restrict the latching to the address in the SDP of the offer from the
access realm (for inbound calls) or the SDP answer (for outbound calls).

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-28

Advanced Media Handling

When do we disable symmetric latching?

In this case, if we enable symmetric-latching on both sides of the Net-Net SDs,
they both will wait to receive the first RTP packet in order to latch the flow and
use this information as destination in the reverse flow. Because both are
waiting for this first RTP packet, neither of them will send RTP to the backbone.
The result is that no RTP packets are sent to the endpoints. Ensuring
symmetric latching is disabled in the backbone realms in both Net-Net SDs will
resolve the issue.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-29

Advanced Media Handling

Completing the NAT Entries

The NAT CAM entries are completed on receipt of the final response from the
called party (i.e., a 200 OK). Note that the Source Addresses and Ports are not
populated as they are not indicated in the signaling messages. Rather, the Net-
Net 4000 must latch onto the SAs and SPs from the first RTP packet received
for that dialog.
For the CAM entries from the side of the NAT device towards the Net-Net SD,
SP_flow_Key must be populated.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-30

Advanced Media Handling

Client Requirements for HNT

There are several assumptions made in an HNT solution. It is assumed that
the firewall will support symmetric signaling and media.
We normally call them Firewalls, but most of the time they are a combination of
firewall and NAT devices.
The reason why we force this symmetric signaling and RTP/RTCP is because
the Net-Net SD will latch the incoming flow and will use the same IP and port as
the destination of the reverse flow. If the endpoint of the Firewall in between
does not accept packets incoming at this port, this direction of the flow will fail,
resulting in wrong signaling or a one-way media problem.
It is highly recommended to send early media to latch the flow as soon as
possible and be able to send media in the reverse direction, but also to send at
least one RTP packet every 10 seconds to reset the media timers for that flow.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-31

Advanced Media Handling

Early Media
This slide explains what is SIP early media suppression and how to configure it.
The Net-Net SD lets you determine who can send early media and in what
direction. Early media are the RTP/RTCP packets sent from the called party to
the caller, or vice versa, before a session is fully established (before a 200 OK
is received). When the Net-Net SD receives an INVITE message with SDP, it
can forward media packets to the calling endpoint as soon as it forwards the
INVITE to the next hop. It can also forward media packets received from the
calling endpoint to the called endpoint as soon as the Net-Net SD receives SDP
in a SIP response to the INVITE, usually a provisional message. This allows for
any early media to be played, such as remote ring back or announcement.
Early media can be unidirectional or bidirectional, and can be generated by the
caller, the callee, or both. With early media suppression, you can block early
media until the call is established. You can define which outbound realms or
next hop session agents are allowed to send or receive early media. early
media suppression only applies to RTP packets. RTCP packets received by the
Net-Net SD are still forwarded to their destination in both directions, unless an
endpoint is behind a NAT and the media manager has not been enabled for
RTCP forwarding.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-32

Advanced Media Handling

Early media Suppression

With the SIP-based addressing, early media suppression is based on the
outbound SIP interface realms and the value of their early-media-allow
parameter. When the Net-Net SD forwards a SIP Invite out a SIP interface, the
outbound realm is chosen based on the SIP layer information, such as the
session agent for the next-hop or the address prefix of the next-hop SIP device.
The matching realm’s early-media-allow parameter value then applies to either
allow all, block all, or block one-way early media until a 200 ok is received. At
that point bidirectional media is allowed. The decision is based on SIP-layer
addressing of next-hops.
You configure a rule for a realm or a session agent to use early media
suppression.
An early media suppression rule specifies whether you want to prevent early
media in any direction, allow early media going to the calling endpoint in the
reverse direction, or allow early media in both directions. The forward direction
is when the packets flow from the caller to the called party. The reverse
direction is when the packets flow from the called party to the caller.
The early media suppression rule is applied to a session. When the Net-Net SD
initiates a new session, it first checks whether the next hop is a session agent
and if so, whether an early media suppression rule has been configured. If an
early media suppression rule is found, the Net-Net SD enforces it. If the next
hop is not a session agent or no early media suppression rule is configured, the
Net-Net SD checks whether an early media suppression rule has been
configured for the outbound realm. If it finds one, it enforces it.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-33

Advanced Media Handling

Topic Review: Media Concepts

What are the 4 parameters in the realm determining if media will be handle by
the Net-Net SD?
mm-in-system, mm-in-network, mm-in-realm, mm-same-ip

What main information is sent from SIPD to MBCD in a miboco ADD

transaction to built the flows?
IP:port from SDP of Invite, ingress and egress realms

Restricted-latching by default is set to none, what are the other possible

values?
SDP (for the IP of the c: line), peer-ip (for the layer 3 IP)

How would you describe the behavior when delayed-media-update is enabled

in a realm?
Flows and CAM entries are not updated when the offer (INVITE) is
received but when the answer (200OK) is received

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-34

Advanced Media Handling

Topic Exercise: Media Concepts

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-35

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-36

Advanced Media Handling

Steering Pools
Steering pools define sets of ports that are used for steering media flows from
one realm to another, through the Net-Net SD. When the Net-Net SD is
communicating with a SIP device in a specific realm with configured steering
pools, the Net-Net SD will use the IP address and port number (from pool of
ports) to which to send media. The port that the Net-Net SD chooses to use is
identified in the Session Description Protocol (SDP) of the SIP message.
When a call enters the Net-Net SD, the signaling application allocates a port
from all of the eligible steering pools that will be used for the call. Once a port is
chosen, the Net-Net SD checks if the steering pool that the port is from has a
defined network interface. If it does, the call is set up on the corresponding
network interface. If a network interface is not defined for that steering pool, the
network interface defined for the realm is used.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-37

Advanced Media Handling

Steering Pool Configuration

The steering-pool element allows you to provide a target IPv4 address (via the ip-
address field value) and a target port range (via the start-port and end-port parameters)
to steer the flow of media to a location defined by the SIP proxy. Any valid port range
can be used for these fields. When you plan steering pool port ranges, you should take
into account the total sessions available on the box, determine how many ports these
sessions will utilize per media stream, and then assign that number of ports to all of the
steering pools on your Net-Net SD. This will allow for the maximum number of ports
that you would need to use for the box, but not use extra resources on ports your Net-
Net SD is never going to use. For example, if your Net-Net SD can accommodate 500
sessions and each session typically utilizes 2 ports per session, you should assign 1000
ports to each steering pool.
Every steering pool you create includes its own range of ports for media flows. The total
number of ports in all the steering pools that feed into one realm are available for calls
in and out of the realm.
Steering pool ports for a given realm are assigned to media flows sequentially. When
the first call enters the Net-Net SD after start-up, it is assigned the first ports on the first
steering pool that you configured. New calls are assigned to ports sequentially in the
first steering pool. When all ports from the first steering pool are exhausted, the Net-Net
SD uses ports from the next configured steering pool. This continues until the last port
on the last configured steering pool is used.
After the final port is used for the first time, the next port chosen is the one first returned
as empty from the full list of ports in all the steering pools. As media flows are
terminated, the ports they used are returned to the realm’s full steering pool. In this way,
after initially exhausting all ports, the realm takes new, returned ports from the pool in a
“least last used” manner.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-38

Advanced Media Handling

RTP based Call Admission Control

You can configure a form of call-admission-control based on RTP flows through
the Net-Net SD in the steering pool element. You set a valid UDP port range
for RTP flows per IP address. You can set this range to be as large or small as
the number of concurrent sessions (remember that one voice session uses two
ports per steering pool) that you want to allow concurrently. This will also allow
for the maximum number of ports that you would need to use for the box, but
not use extra resources on ports your Net-Net SD is never going to use. For
example, if your Net-Net SD can accommodate 500 sessions and each session
typically utilizes 2 ports per session, you should assign 1000 ports to each
steering pool.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-39

Advanced Media Handling

Nested Realm Group

A group of realms consisting of one or more levels of parent and child realms.
Parent/child realms:
Parent realm: A realm that has one or more child realms
Child realm: A realm that is associated with a single higher order “parent” realm. Inherits
the steering pool and signaling service of the higher order realms
Signaling service
Signaling interface (i.e., SIP interface, H.323 stack, etc.)
Controlling realm
A realm in a realm group for which a signaling service (i.e., SIP Interface, H.323 Stack,
MGCP cfg) is configured.
Ingress/Egress realm
Ingress and egress realms are determined dynamically. Each session’s ingress/egress
realm determines the starting point in the nested realm group for bandwidth
allocation. The signaling service and steering pool are inherited from higher order
realms.
Ingress realm: Determined by matching the originating session agent or the IP address
of the incoming request to the address-prefix of a configured realm.
Egress realm: Determined by application level routing (local policy, registration cache,
SIP-NAT bridge, etc.)

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-40

Advanced Media Handling

Bandwidth-Based CAC and Nested Realm Groups

Multi-level nesting allows for specific bandwidth partitioning. It may be based
on protocol, site, multiple aggregated paths, etc. The Net-Net SD checks each
realm in the path to ensure sufficient bandwidth is available to complete calls.
Realm CAC is configured per-realm and is applied based on either the ingress
or egress realm bandwidth counters. If either the ingress or egress bandwidth
in a realm exceeds the limit, the call is rejected.
Per-user CAC is different in the sense that the maximum bandwidth used from
the east and west flows are applied to both the CALLING and CALLED parties.
The bandwidth policing parameters of the media-profile will be applied based
on the flow’s ingress realm media-profile. In the above examples, traffic from
realm A would be policed based on the realm A policing values and the same
for realm B.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-41

Advanced Media Handling

Important things to remember

The child realms can use signaling or media resources from its parent, but
routing policies must be defined for them specifically. We can modify this
behavior and by setting the parameter match-lp-src-parent-realm to enabled in
the session-router-config element. By doing this, the Net-Net SD, once it has
determined the ingress realm, will go to its highest level parent and will use the
local policies attached to it for routing.
When we say that bandwidth will be deducted from every realm, this is only true
if the steering pool is configured in the parent realm and not in the child realm.
In the case of pseudo-realms, realms that do not contain signaling resources
and have configured Session-Agents, must have a parent realm with configured
signaling interfaces to be selected as the ingress realms. Otherwise, the
ingress realm will be that realm with the configured signaling interface. This is
the basis of the OAI (Open Access Internet) Model used in peering scenarios.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-42

Advanced Media Handling

Per User CAC

With this feature enabled, the Net-Net SD changes behavior so that it will only
allow the configured number of calls or total bandwidth to and from each user in
a particular realm. The overall realm bandwidth and steering pool limits still
apply, and as before, the Net-Net SD still rejects users who might be within
their CAC limitations if accepting them will exceed the bandwidth limitations for
parent or child realms and steering pools.
For SIP sessions, the Net-Net SD now keeps track of the amount of bandwidth
a user consumes and the number of active sessions per address of record
(AoR) or per IP address, depending on the CAC mode you select (either aor or
ip). When an endpoint registers with the Net-Net SD, the SD allots it a total
amount of bandwidth and total number of sessions.
You should note that this functionality only works if you enable registration
caching on your Net-Net SD. You can set the per user CAC bandwidth in realm
configuration, too, and it is handled much the same way that the sessions are
handled. That is, depending on the CAC mode you set, the bandwidth is shared
between contacts for the AoR or the endpoints behind the same IP address. All
endpoints must be registered with the Net-Net SD.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-43

Advanced Media Handling

Bandwidth CAC for realm when media released

The bandwidth CAC for each realm is enabled by setting the parameter max-
bandwidth to a different value than 0 (default value).
The bandwidth CAC for media release feature adds per-realm configuration
that determines whether or not to include inter-realm calls in bandwidth
calculations. When you enable this feature, the Net-Net SD’s behavior is to
count and subtract bandwidth from the used bandwidth for a realm when a call
within a single site has its media released. When you do not enable this feature
(and the Net-Net SD’s previous behavior), the Net-Net SD does not subtract the
amount of bandwidth.
In other words:
•When you enable this feature, an inter-realm media-released call will
decrement the maximum bandwidth allowed in that realm with the bandwidth
used for that call.
•When you disable this feature (default behavior), an inter-realm media
released call will not decrement the maximum bandwidth allowed for that call.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-44

Advanced Media Handling

Viewing MBCD per realm statistics

The show mbcd realms command provides a view of media consumable
resources, such as bandwidth and steering pool ports.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-45

Advanced Media Handling

Media Profiles per codec

You can load any configured media profiles. Load all media profiles from the default list
that don’t conflict with the configured profiles in terms of encoding or payload.
The following is the current list of default media profiles:
Type Payload Encoding Bandwidth
“audio” "0" "PCMU" 0
“audio” "2" "G726-32" 0
“audio” "4" "G723" 0
“audio” "8" "PCMA" 0
“audio” "9" "G722" 0
“audio” "15" "G728" 0
“audio” "18" "G729" 0
“audio” "101" "telephone-events" 0
Example 1) A media profile has been configured as follows
Encoding=PCMU Payload=0
The default PCMU profile will not be loaded because both the encoding and payload
conflict with a configured profile.
Example 2) A media profile has been configured as follows:
Encoding=FOO Payload=18
The default G729 profile will not be loaded because the G729 payload(18) conflicts with
a configured profile. If Encoding matches but not the Payload, the default profile will not
be loaded.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-46

Advanced Media Handling

Media processing
RTP processing is entirely hardware-based (the Host subsystem is not
involved). Received RTP packets are treated in the same way as signaling
packets in the Network Processor subsystem, with one exception—CAM
lookups must yield exact matches, or the RTP packet is dropped. These exact
match entries are instantiated by the Host Subsystem based on successful call
setup signaling.
If an average-rate-limit value is set in a media-profile that matches this call or
flow, then a buffer of 4 kbs is assigned to each flow and the packets ingress
any speed but egress at the rate limit set in this parameter. If this rate is
exceeded, the buffer will be full and packets will start to be dropped.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-47

Advanced Media Handling

Topic Review: BW CAC

If I have media profiles configured for a particular codec, what must be set as
parameter to perform traffic shaping?
Average-rate-limit

Which command can you use to see the used bandwidth per realm? Can you
see if calls have been rejected for no BW?
Show mbcd realms. Yes you will see the number of flows rejected for
insufficient BW

In Nested realms, do sub-realms use by default the Local-policies of their

parents? If not, can we make this happen? How?
Not by default, you must enable the parameter match-lp-src-parent-
realm in the session-router-config element

Mention two ways to separate signaling and media in the Net-Net SD in

different VLANs?
By setting a different Network-interface for media in the steering pool
By using Nested realms and assign SP and signaling to different
Network-interfaces

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-48

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-49

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-50

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-51

Advanced Media Handling

QoS main parameters

The three main measurements to take into consideration are:
• Delay - Packets takes time to arrive to its destination, due to the
nature of the routing network, the wire, and the time needed for
encoding/decoding the voice.
• Jitter - The network is dynamic and may suffer congestion and
overload problems. Therefore different voice packets associated to
the same session may suffer different delays. This delay variation is
called Jitter.
• Packet Loss - Due to buffer size, collisions, non connection oriented
networks and the impossibility of retransmit packets, we may
encounter a number of packets lost in the path.
All 3 of these measurements are taken in the receive direction from the RTP
packets, but in order to collect them for the transmit direction, the device should
receive and read RTCP protocol.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-52

Advanced Media Handling

Quality of Service (QoS)

The basic goal of Quality of Service (QoS) is to provide service differentiation
between IP packets in the network. This service differentiation is noticeable
during periods of network congestion (i.e. in case of contention for resources)
and results in different levels of network performance.
The implementation of QoS in most VoIP networks is based on the
Differentiated Services (DiffServ) model, as defined by the Internet Engineering
Task Force (IETF). This implies that each packet is marked with a DiffServ
CodePoint (DSCP) in its IP header. The DSCP value is stored in the first 6 bits
of the Type of Service (ToS) field/byte that is part of the standard IP header.
The DSCP values are associated with a certain forwarding treatment, also
called Per Hop Behaviors (PHB). By configuring PHBs in each router of the
network, an edge-to-edge service can be provisioned.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-53

Advanced Media Handling

Configuring Diffserv on the Net-Net SD

To mark packets from the Net-Net SD, we need to configure a media-policy
element. This element includes:
• Name - Where we need to enter the unique name of this media
policy.
• Tos-settings - Child element, where we enter the media type, media-
sub-type and TOS value for this media policy.
• media-type - Enter the media type you want to use for this media
profile. The valid values are:
• audio
• video
• application
• data
• image
• text
• tos-values - Enter the TOS values to use for this media type. The
valid range is:
• 0x00 to 0xFF
You may assign tos-values as hexadecimal or decimal.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-54

Advanced Media Handling

RADIUS Accounting
Although Remote Authentication Dial-In User Service (RADIUS) is traditionally
associated with billing by way of Call Detail Records (CDRs), in the case of the
Net-Net SD, it can be used to provide useful QoS information, too.
RADIUS CDRs facilitate end-to-end QoS and troubleshooting by way of
including Delay, Jitter, Packet Loss measurements and also pre and post
NATted message information, including CALL-IDs, which change.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-55

Advanced Media Handling

Real-Time Accounting
Each Net-Net SD may generate multiple CDRs on a single call (call start, interim
change(s) and call end) in real-time. They are not batched, rather sent directly when
generated (by default). Currently, the Net-Net OS RADIUS implementation supports
CDRs for SIP and H.323 only. Acme Packet has a RADIUS dictionary available for
download from the Customer Portal, which includes the Vendor Specific Attributes
(VSAs) supported on the Net-Net SD 4000 or 9000 Series.
RADIUS accounting is configured under configure>session-router>account-config. It is
a single-instance object, potentially with multiple children objects. The strategy property
specifies how the SD should load balance between multiple configured RADIUS
servers. Choices include Hunt, Failover, Round Robin, Fastest Round Trip Time and
Fewest Pending.
The trans-at-close property in account-config indicates whether to send a CDR at the
end of a session only (enabled) or at call start and call end (disabled)
RADIUS accounting servers are configured under configure>session-router>account-
config>account-servers. This is a multiple-instance object. You may configure zero or
more RADIUS accounting servers. The hostname property indicates where to send
CDRs and may take the form of an IP Address. The secret property represents the
shared secret with the RADIUS accounting server (where it must also be configured).
The NAS-ID is the remote accounting server ID.
Remember that RADIUS CDRs, like all management traffic originating in the Net-Net
4000 Series, will be sent out the Wancom0 (eth0/mgt0) interface. As such, it is
important to ensure that the configured RADIUS servers are reachable via this interface.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-56

Advanced Media Handling

Call Detail Records Meanings

For every CDR that is generated we could find hundreds of fields. Some of
them are self explanatory but others could be hard to guess the meaning.
By default, the Net-Net SD collects information for two bidirectional Flow Sets
(FS) per signaling call, for example one voice and one video. If we always work
with only one Flow, then all data related to FS2 is irrelevant.
Forward (F) specify the direction of the flow from the calling to the called party.
Reverse (R) indicates the flow in the direction from the called party to the
calling.
The words Calling and Called are also used when the Net-Net SD assigns
values to the QoS Attributes, like delay, jitter or packet loss.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-57

Advanced Media Handling

CDR Content
VSAs are grouped according to attribute function. This table contains the sections
shown below.
General Attributes—Overall traits of the session, these attributes appear in all CDRs
regardless of the session’s protocol; these attribute fields are time-zone, Sequence
number, etc
General Flow Attributes—Overall traits of the media flow, these attributes appear in all
CDRs regardless of the session’s protocol; these attribute fields are only populated if
there are media flows
Inbound Flow Attributes—Detailed traits of the inbound media flow (including realm,
remote IP address and port, and local IP address and port); these attribute fields are
only populated if there are media flows
Outbound Flow Attributes—Detailed traits of the outbound media flow (including realm,
remote IP address and port, and local IP address and port); these attribute field are only
populated if there are media flows
Session Attributes—Information about the protocol type, ingress and egress realms
used, and an identifier that links the H.323 and SIP legs of a call requiring IWF
QoS Attributes—RADIUS call records are instantiated by individual signaling
applications on the Net-Net SD. The Net-Net SD writes the following additional
parameters to the call record for QoS (Quality of Service):
RTP Lost packets, RTP Jitter, RTP Maximum Jitter
RTCP Lost packets, RTCP Jitter, RTCP Latency, RTCP Maximum Latency
RTP Total Packets, RTP Total Octets
Only RADIUS Stop records contain QoS information. For non-QoS calls, the attributes
appear in the record, but their values are always be zero (0). When you review the list of
QoS VSAs, please note that “calling” in the attribute name means the information is sent
by the calling party and “called” in the attribute name means the information is sent by
the called party.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-58

Advanced Media Handling

VSA ID range selection

To enter a list of RADIUS attributes to include in a CDR:
1. vsa-id-range—Enter a comma-delimited list that represents the VSA you
want to appear in the RADIUS CDR. There is no default for this parameter.
Do not use <Spaces> when typing in your comma-delimited list.
Training (account-config)# vsa-id-range -5,7,10-
This entry specifies that CDRs contain VSA with identifiers equal to and less
than 5, VSA 7, and VSAs with identifiers equal to and greater than 10.
2. Save and activate your configuration
You enter the list of VSAs that you want included as a comma-delimited list.
There are special entry types you can use in the comma-delimited list to set
ranges and make entries easier:
• X- — Where X is a VSA identifier, the Net-Net SD will include all
attributes with an identifier equal to or greater than X.
• -X — Where X is a VSA identifier, the Net-Net SD will include all
attributes with an identifier equal to or less than X.
• - — Use the minus sign (-) alone when you want to turn off attribute
selection, including all VSAs in the CDR.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-59

Advanced Media Handling

CDRs customized values by HMRs

This feature enhances the generation of CDR records allowing customers to
add up to 31 user configurable VSAs (in the number range 200-230) extracted
from previous customized HMRs.
By using the vsa-id-range parameter of the account-config element, the user
can also decide which of the VSA fields will appear in the CDRs, including the
standard ones or the customized by HMRs.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-60

Advanced Media Handling

Verify that your Net-Net SD is able to send QoS

1) training1# show prom-info mainboard
Contents of Main Board PROM
Assy, Session Director II with QOS
Part Number: 102-1002-52
Serial Number: 090642000236
Functional Rev: 2.10
Board Rev: 3
PCB Family Type: Session Director
ID: Session Director II with QOS
…
Number of MAC Addresses:16
Starting MAC Address: 00 08 25 a0 08 80
2) training1# show features
Total session capacity: 32000
Enabled features: SIP, MGCP, H323, IWF, QOS, ACP, Routing, Load Balancing,
Accounting, High Availability, PAC, External BW Mgmt, External Policy Services,
ENUM, H248
3) Verify Account-config and qos-enabled parameter set to enabled in the realm

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-61

Advanced Media Handling

Codec policies
You can configure a codec policy to perform several different kinds of manipulations.
The allow and order manipulations are described below.
• Allow — List of codecs that are allowed for a certain codec policy; if a codec does
not appear on this list, then the Net-Net SD removes it. You can wildcard this list
with an asterisk (*) so that all codecs are allowed. Further, you can create
exceptions to a wildcarded allow list. You make an exception to the wildcarded list
of codecs by entering the codec(s) that are not allowed with a no attribute. This tells
the Net-Net
SD to allow all codecs except the one(s) you specify. i.e. Training (codec-policy)#
allow-codecs * PCMA:no
You can also create exceptions to allow lists such that audio or video codecs are
removed. However, when the allow list specifies the removal of
all audio codecs and an INVITE arrives at the Net-Net SD with only audio codecs, the
Net-Net SD behaves in accordance with RFC 3264. This
means that the resulting SDP will contain one attribute line, with the media port for
the media line set to 0. The terminating side will need to
supply new SDP in its reply because the result of the manipulation is the same as an
INVITE with no body.
Training (codec-policy)# allow-codecs * audio:no
• Order — List of the codecs where you specify their preferred order in the outgoing
media offer. The Net-Net SD arranges matching codecs according to the rule you
set, and any remaining ones are added to the list in the same relative order they
took in the incoming media offer. If your list specifies a codec that is not present,
then the ordering proceeds as specified but skips the missing codec.

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-62

Advanced Media Handling

Codec policy configuration

You can use an asterisk (*) as a wildcard in this list, too. The placement of the asterisk
is key, as you can see in the following examples:
• For an order rule set this way: Training (codec-policy)# order A B C *
codecs A, B, and C will be placed at the front of the codec list in the order specified; all
other codecs in the offer will follow A, B, and C in the same relative order they had in
the original SDP offer.
• For an order rule set this way: Training (codec-policy)# order A * B C
codec A will be placed at the beginning of the codec list, to be followed by all other
codecs in the offer in the same relative order they had in the original SDP offer, and
then B and C will end the list.
• Force—An attribute you can use in the allow list with one codec to specify that all other
codecs should be stripped from the outgoing offer. You can specify multiple forced
codecs in your rules.
• If you set multiple codecs in the allow list and one of them is forced, then the outgoing
offer will contain the forced codec.
• If you set multiple codecs in the allow list and the one that is forced is not present in
the offer, then the Net-Net SD will select a non-forced codec for the outgoing offer.
Training (codec-policy)# allow PCMU G729:force
You cannot use the force attribute with a wildcarded allow list.
• No—An attribute that allows you to strip specified codecs or codec types from a
wildcarded allow list.
Training (codec-policy)# allow * PCMA:no

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-63

Advanced Media Handling

Topic Review: QoS and Codec policies

If I have an RTP packet arriving to the Net-Net SD already marked, do I need
TOS settings? Why?
Yes, because the Net-Net SD removes and recreate IP headers

How can I use a different DiffServ value for video and voice?
Configuring the media-policy with 2 tos-settings, one for media-type
video and another one for audio

How many Flow Sets for a single call can I get QoS from? How are they
identified?
Two, they are called FS1 and FS2 (Flow set)

What two main actions can I achieve with codec policies?

Remove a codec or reorder the list of offered codecs

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-64

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-65

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-66

Advanced Media Handling

Copyright © 2012 Acme Packet, Inc. admh.6.j.pm-67